Freaks Macintosh Archive

home *** CD-ROM | disk | FTP | other *** search

/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Phreaking⁄Wardialers / Phreaking texts / 5ESSManual1.txt < prev next >

Wrap

Text File | 1999-01-28 | 1MB | 21,772 lines

Note: The 235-XXX-XXX manuals do not provide maintenance procedures for the repair of equipment (for example, tape drives or disk drives) manufactured by vendors other than AT&T. To identify the appropriate maintenance manual for each unit of such vendor equipment, refer to Section 3 of AT&T 235-001-001, Documentation Description and Ordering Guide. This guide only provides the vendor's address associated to the unit in question, not the procedures used to repair the faulty equipment. This document describes the maintenance concepts and built-in maintenance capabilities of the 5ESS(R) switch. The information is necessary to perform system evaluation and maintenance. To be adequately prepared to maintain the 5ESS switch, the following prerequisites are recommended for maintenance personnel: a. Must be familiar with telephone equipment and terminology. b. Must complete maintenance training on the 5ESS switch. c. Must be familiar with the information in the following manual(s): o AT&T 235-100-125, System Description 5E6 and Later o AT&T 235-900-106, Product Specification 5E6 o AT&T 235-900-107, Product Specification 5E7 o AT&T 235-900-108, Product Specification 5E8. o AT&T 235-900-109, Product Specification 5E9(1). Note: These manuals also contain a section concerning Environmental Specifications (physical specifications) that can be useful to maintenance personnel. Product rating for the 5E2(2), 5E3, 5E4, and 5E5 software releases has been changed to Discontinued Availability (DA). Effective with Issue 7.00, all information on the DA rated software releases is being removed from this document. This document is updated to provide coverage for the 5E7 (Issue 5.00), 5E8 (Issues 6.00 and 6.01), and 5E9(1) (Issue 7.00) software releases. Sections .RM 1.2.2/, .RM 1.2.3/, and .RM 1.2.4/, respectively, contain update information on these software releases. Note: The 5E2(2) through 5E5 information is removed in Issue 7.00 of this document. (See statement relative to DA rating of software releases at the beginning Section .RM 1.2.1/.) For the 5E7 software release, Issue 5.00 of this document was updated for the following reasons: o Removed information on the 5E2(1) software release from all sections. [All 5E2(1) offices have been retrofitted to a later software release.] o Updated Table .AW TA/. o Changed information on the Call Monitor feature is Sections 2 and 3. o Updated information on the Office Data Base Editor (ODBE) is Section 3. o Updated information on the Access Editor (ACCED) is Section 3. o Updated information on the Current Update Data Base and History File Editor (UPedcud) is Section 3. o Made screen corrections, added screen abbreviations, and added command descriptions on Trunk and Line Work Station (TLWS) Task Selection Pages for 5E2(2) through 5E6 software releases in Section 3. o Added information on TLWS Task Selection Pages for the 5E7 software release in Section 3. Note: Information on TLWS task selection pages and commands is completely rewritten in Issue 7.00 of this document. o Reorganized and reformatted information on Generic Utilities to present information on this tool in a more descriptive format as opposed to the redundant Input/Output message data included in previous issues. o Added the master control center (MCC) Page Location Guide to the Introduction subsection in Section 4. Note: In Issue 7.00, the title of the Introduction subsection is changed to Introduction to MCC Pages. o Updated, added, and deleted text and screen displays in Subsections 5E2(2) through 5E6. These updates, additions, and deletions were the result of in-depth reviews for accuracy of all MCC page displays and associated text by BTL developers. o Added the 5E7 Subsection to Section 4. The 5E7 Subsection contains the MCC page displays that changed with the 5E7 software release. o Made minor corrections to text, tables, and figures throughout the document. Note: The 5E2(2) through 5E5 information is removed in Issue 7.00 of this document. (See statement relative to DA rating of software releases at the beginning Section .RM 1.2.1/.) For the 5E8 software release, Issues 6.00 and 6.01 of this document were updated for the following reasons: o Updated Table .AW TA/. o Updated information on Software Release Retrofit/Update/Large Terminal Growth in Section 2. o Updated information on Access Editor (ACCED) in Section 3. o Added information on Common Network Interface Data Base Consolidator (CNIDBOC) in Section 3. o Updated information on BROWSE in Section 3. o Updated information on Generic Access Package (GRASP) in Section 3. o Updated information on the Operation Support System (OSS) Routine Exercises (REX) Scheduler Program in Section 3. o Added information on the Automatic REX Scheduler in Section 3. o Added information on the 108-type test line in Section 3. o Added information on basic rate interface (BRI) access to the 108-type test line in Section 3. o Added information on Trunk and Line Work Station (TLWS) Task Selection Pages for the 5E8 software release in Section 3. Note: Information on TLWS task selection pages and commands is completely rewritten in Issue 7.00 of this document. o Updated the Generic Utilities information in Section 3 to add commands for two new 5E8 processors, Integrated Digital Carrier Unit (IDCU) and Integrated Digital Carrier Unit Loop Side Interface (IDCULSI). o Updated information in Table .AW TAD/, Directory of Service Centers. o Updated information in Table .AW TAE/, Directory of Service Support Organizations. o Updated the master control center (MCC) Page Location Guide in the Introduction subsection of Section 4. The update included adding all MCC pages in the 5E8 subsection. Note: In Issue 7.00, the title of the Introduction subsection is changed to Introduction to MCC Pages. o Updated the general description of the 1000 SM Page Index page in 5E2(2) through 5E7 subsections. o Updated information on MCC Page 105/106 in the 5E2(2) subsection. o Updated information on MCC Page 1950 in the 5E5 subsection. o Updated information on MCC Pages 115 (CM2 version), 116, and 1950 in the 5E6 subsection. o Updated information on MCC Pages 110, 116, 123, 125, 1800,X, 1850, and 1851 in the 5E7 subsection. o Removed information on MCC Page 1950 from the 5E7 Subsection. (The update to the 1950 page in the 5E6 Subsection applies to 5E6 and later software releases.) o Added the 5E8 Subsection to Section 4. The 5E8 Subsection contains the MCC page displays that were added with or changed with the 5E8 software release. o Made minor corrections to text, tables, and figures throughout the document. This document is updated to Issue 7.00B, May 1994, to add the results of call failures in Section .RM 3.5.1.10/, Call Monitor Reports. This document is updated to Issue 7.00A, December 1993, for the following reasons: o To remove the requirement for circuit packs to be tested on site o To add the DGR state to MCC page 118 o To update information on MCC pages 1521,XX and 1522,XX,Y. o To add a note for the user to insert RC/V view 8.3 if it does not exist. For the 5E9(1) software release, Issue 7.00 of this document is updated for the following reasons: o Update Table .AW TA/. o Update information on the Call Monitor in Sections 2 and 3. o Update Single Process Purge and Selective Initialization information in Section 2 to include wideband calls. o Add information on the automatic trunk test scheduler (ATTS) in Section 3. o Update Trunk and Line Work Station (TLWS) information in Section 3 for 32 test positions in 5E9(1) and to include test position resources and resource assignment. o Update line and trunk testing information in Section 3 to include wideband calls. o Change the format of information on TLWS Task Selection Pages in Section 3 to eliminate redundancy and reduce the number of text pages. o Add 5E9(1) examples of all TLWS pages to reflect new page layout and command changes and add information on new 5E9(1) Pages 5000,3 (line), 5000,3 (trunk), 8000, 9000,1, 9000,2, and 9201. o Add information on input message editing and history in Section 3. o Add information on the Ring Generic Access Package (RGRASP) in Section 3. o Add information on the Automated Circuit Pack Return Tag (RTAG) tool in Section 3. o Add information on the Automated Static ODD (SODD) Audit in Section 3. o Update the master control center (MCC) Page Location Guide in the Introduction to MCC Pages (formerly Introduction) subsection of Section 4. The update includes removing references to the 5E2(2) through 5E5 software releases and adding references for all MCC pages included in the 5E9(1) subsection. o Remove subsections 5E2(2) through 5E5 in Section 4 and move to the 5E6 subsection all MCC page displays valid for 5E6 (or 5E6 and later) that were previously included in subsections 5E2(2) through 5E5. o Add the 5E9(1) subsection to Section 4. The 5E9(1) subsection contains MCC page displays that were added with or changed with the 5E9(1) software release. o Make minor corrections to text, tables, and figures throughout the document. The information in this document is applicable to all switches equipped with 5E6 and later software releases. When text applies to a specific software release, the applicable software release is indicated. When new software releases are developed that affect this document, updates will be made. Also, this document is utilizing an issue number. The overall structure is outlined as follows: 1. Section 1--Introduction: This section summarizes the type of information contained in the document, gives the purpose of this information, and defines its organization. In addition, this section identifies the three maintenance manuals provided for maintenance and explains the function of each. 2. Section 2--Maintenance Philosophy: This section describes the following maintenance capabilities of the 5ESS switch: o Maintenance overview. o Remote maintenance capabilities. o Central office maintenance plan. o System evaluation and maintenance stimuli. o Maintenance tasks: a. Scheduled routine maintenance b. Nonscheduled routine maintenance c. Corrective maintenance tasks d. System recovery e. Operator Services Position System (OSPS) maintenance f. Maintenance of vendor equipment. o Line unit trouble clearing guide. o Trunk and line maintenance: a. Per-call tests b. Routine line and trunk tests c. Tests provided d. Call monitor. o Recent change (RC), field, and software release retrofit/update. o Change notices (CN). 3. Section 3--Maintenance Tools: This section describes the following maintenance tools available for use in the 5ESS switch: o Display administration process (DAP)/Non-DAP terminal. o MCC. o Supplementary trunk and line work station (STLWS). o TLWS. o Trunk and line maintenance. o Test access unit (TAU). o Directly connected test unit (DCTU). o Remote office test line (ROTL). o TLWS task selection page displays. o Recent change/verify (RC/V). o Screen program user's guide. o How to use input/output (I/O) messages. o Office data base editor (ODBE). o Access editor (ACCED). o Common network interface data base consolidator (CNIDBOC). o Automated circuit pack return tag (RTAG) tool. o Software debugging and troubleshooting tools. o Generic utilities. o System log files. o Diagnostics: -- Diagnostic types -- Diagnostic input/output messages -- Routine exercises (REX) -- Operation Support System (OSS) REX scheduler program -- Automatic REX scheduler. o How to use switching module (SM) peripheral Fault Recovery Message (Verbose Mode). o Routine tests. o How to use office backup schedules. o Circuit pack handling procedures. o Spare circuit packs. o Circuit pack repair service and return procedures. o Dynamic Audits. o Static Audits. o How to use program record and program map documents. o How to use program change document, symbol address cross-reference index, and function address program record (PR) name cross-reference index. o TR303 Integrated Digital Carrier Unit (IDCU) remote terminal provisioning. 4. Section 4--MCC Page Display: This section contains a detailed description of the page displays of the 5ESS switch MCC video terminal and the MCC Page Location Guide which can be used to locate specific page displays for specific 5E6 and later software releases. Section 4 is divided into five subsections as follows: o Section .RM 4.2/: Covers the introduction to the MCC page displays o Section .RM 4.3/: Covers the 5E6 software release o Section .RM 4.4/: Covers the 5E7 software release o Section .RM 4.5/: Covers the 5E8 software release o Section .RM 4.6/: Covers the 5E9(1) software release. Since this document has been developed to describe maintenance concepts and maintenance capabilities for the 5ESS switch, it is appropriate to identify the manuals that contain the procedures used to maintain the switch. 1. AT&T 235-105-210, Routine Operations and Maintenance Procedures: Contains the descriptive material and detailed procedures for routine operations and maintenance of the 5ESS switch. The following is a list of the sections in this document: o Equipment Test List (ETL) o Operations (system control functions) o Memory Alteration Description o Memory Alteration Procedures o Abnormal Input Message Acknowledgments o Fan and Alarm Tests o Moving Head Disk (MHD) Procedures o Miscellaneous Routine Procedures o ROTL o Routine Exercise Procedures. The AT&T 235-105-210 also has a job aid for O&M Checklist which must be ordered separately (see AT&T 235-001-001, Documentation Description and Ordering Guide). Note: Refer to Table .AW TA/ for a complete list of the operation and maintenance procedures included in AT&T 235-105-210. 2. AT&T 235-105-220, Corrective Maintenance Procedures: Contains three sections as follows: o Hardware - Maintenance Procedures: This section contains a series of task-oriented corrective maintenance procedures that can be used by personnel who are involved in maintaining various hardware units and circuits of the 5ESS switch. Also, some procedures are used to resolve subscribing customer service complaints. o Office Dependent Data - Maintenance Procedures: This section contains a series of task-oriented corrective maintenance procedures that can be used to maintain and repair office dependent data (ODD) associated with the switch. o Supporting Information: This section contains a tabular list that describes all the diagnostic phase descriptions and a Basic Rate Interface (BRI) trouble-shooting diagram. The AT&T 235-105-220 also has a group of job aids for the TLWS poke commands which must be ordered separately (see AT&T 235-001-001, Documentation Description and Ordering Guide). Note: Refer to Table .AW TA/ for a complete list of the operation and maintenance procedures included in AT&T 235-105-220. 3. AT&T 235-105-250, System Recovery: Contains the descriptive material and detailed procedures of the software and hardware recovery capabilities of the 5ESS switch. Both automatic and manual recovery capabilities are covered. The following is a list identifying what is covered in this manual: o System Recovery Description: In the 5ESS switch, system recovery uses the concept of a network of independent processors to localize recovery actions. The major processors involved are the administrative module (AM), communication module processor (CMP) (added in the 5E6 software release), and the individual SMs. When a fault exists, fault recovery attempts to reconfigure the system to provide full system service (primarily by excluding the faulty unit). Several levels of recovery are available, and the system can automatically escalate to higher and broader levels if initial attempts fail. The higher recovery levels often include processor initializations. This section describes the various recovery levels (and their impact) when used in the different processors. The strategy of reconfiguration and escalation to higher recovery levels is also covered, as is the mapping between manual commands and internal recovery levels. o System Recovery Procedures: The procedures provided in this section are used to clear system failures which prevent the 5ESS switch from restoring itself automatically. Also, procedures are provided for analyzing the AM and SM initializations. Note: Refer to Table .AW TA/ for a complete list of the operation and maintenance procedures included in AT&T 235- 105-250. 4. AT&T 235-105-119, Maintenance Guide Utilizing OMS5: This document provides information related to utilization of the OMS5 program. The OMS5 program summarizes the receive-only printer (ROP) output into a readable format. This program provides the maintenance personnel with an easy way to analyze how the office is performing. After analyzing the OMS5 program summary, the maintenance personnel should use the Corrective and Routine Maintenance Manuals (listed previously) with this manual to correct faults that occur in the switch. The OMS5 program runs on the switching control center (SCC) minicomputer. The tape that contains the OMS5 program can be obtained via the order number AT&T 235-105-120. This maintenance guide and the OMS5 program can only be used via the SCC. The producers of this manual are constantly striving to improve quality and usability. Please use the enclosed user feedback form [REF. .RM 1.9/] for your comments and to advise us of any errors. If the form is missing or your comments will not fit, you can write to the following address: AT&T NETWORK SYSTEMS Quality Department 2400 Reynolda Road Winston-Salem, NC 27106 Please include the issue number and/or date of the manual, your complete mailing address, and telephone number. We will attempt to answer all correspondence within 30 days, informing you of the disposition of your comments. You may also call our Documentation HOT LINE if you need an immediate answer to a documentation question. This HOT LINE is not intended to eliminate the use of the user feedback form, but rather to enhance the comment process. The HOTLINE number is 1-800-334-0404 and it is available from 7:30 a.m. to 4:30 p.m. Eastern time (within North Carolina, dial 1-910-727-6681). Outside of those hours, the line is served by an answering machine. You can leave a message on the answering machine and someone will return your call the following business day. Also, document users who have access to UNIX(R) system electronic mail facilities may send comments via electronic mail. The electronic address is att!wrddo!hotline5. Please make sure that the document title, number, and issue number are included in the mail along with the sender's name, phone number, and address. This manual is distributed by the AT&T Customer Information Center in Indianapolis, Indiana. Most operating telephone companies should place orders through their documentation coordinator. Some companies may allow customers to order directly from the Customer Information Center; however, the majority do not. Companies that use documentation coordinators to manage their orders receive a significant discount. If you do not know the name/number of the documentation coordinator for your company, you may call 1-800-432-6600 to obtain the name and telephone number. Customers not represented by a documentation coordinator and AT&T employees can order the documentation for the 5ESS switch directly from the AT&T Customer Information Center. Proper billing information must be provided. These orders may be mailed to: AT&T Customer Information Center Order Entry 2855 N. Franklin Road Indianapolis, IN 46219 Orders may also be called in on 1-800-432-6600 or faxed in on 1-317-322-6484. Technical assistance for the 5ESS switch can be obtained by calling the Regional Technical Assistance Center (RTAC) at 1-800-225-RTAC. This telephone number is monitored 24 hours a day, 7 days a week. During regular business hours, your call will be answered by your local RTAC. Outside of normal business hours, all calls will be answered at a centralized technical assistance center where service-affecting problems will be dispatched immediately to your local RTAC. All other problems will be referred to your local RTAC on the next regular business day. How Are We Doing? \ \ Document Title: SYSTEM MAINTENANCE REQUIREMENTS AND TOOLS Document Number: AT&T 235-105-110 Issue Number: 7.00 Publication Date: November 1993 AT&T welcomes your feedback on this document. Your comments can be of great value in helping us improve our documentation. 1. Please rate the effectiveness of this document in the following areas: 4 ____________________________________________________________________ | | | | | | Not | | | Excellent | Good | Fair | Poor | Applicable | |______________________|___________|______|______|______|____________| | Ease of Use | | | | | ///////// | |______________________|___________|______|______|______|____________| | Clarity | | | | | ///////// | |______________________|___________|______|______|______|____________| | Completeness | | | | | ///////// | |______________________|___________|______|______|______|____________| | Accuracy | | | | | ///////// | |______________________|___________|______|______|______|____________| | Organization | | | | | ///////// | |______________________|___________|______|______|______|____________| | Appearance | | | | | ///////// | |______________________|___________|______|______|______|____________| | Examples | | | | | | |______________________|___________|______|______|______|____________| | Illustrations | | | | | ///////// | |______________________|___________|______|______|______|____________| | Overall Satisfaction | | | | | ///////// | |______________________|___________|______|______|______|____________| 2. Please check the ways you feel we could improve this document: [] Improve the [] Make it more concise/brief overview/introduction [] Add more step-by-step [] Improve the table of procedures/tutorials contents [] Add more troubleshooting information [] Improve the organization [] Make it less technical [] Include more figures [] Add more/better quick reference [] Add more examples aids [] Add more detail [] Improve the index Please provide details for the suggested improvement._________________ ______________________________________________________________________ 3. What did you like most about this document? ______________________________________________________________________ ______________________________________________________________________ 4. Feel free to write any comments below or on an attached sheet. ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ If we may contact you concerning your comments, please complete the following: Name: ______________________________ Telephone Number: (___)__________ Company/Organization: ___________________ Date: ______________ Address: ______________________________________________________________ When you have completed this form, please fold, tape, and return to the following address or Fax to: 910-727-3043. DOCUMENTATION SERVICES 2400 Reynolda Road Winston-Salem, NC 27199-2029 The following is a list of manuals that the user should be aware of when reading this document: o AT&T 235-600-700, 5ESS Switch Input Messages Manual o AT&T 235-600-750, 5ESS Switch Output Messages Manual o AT&T 235-105-119, Maintenance Guide Utilizing OMS5 o AT&T 235-105-210, Routine Operations and Maintenance Procedures o AT&T 235-105-220, Corrective Maintenance Procedures o AT&T 235-105-250, System Recovery o AT&T 235-600-104, Translations Data 5E6 o AT&T 235-600-105, Translations Data 5E7 o AT&T 235-600-106, Translations Data 5E8 o AT&T 235-600-107, Translations Data 5E9 o AT&T 235-600-400, Audits Manual o AT&T 235-600-500, Asserts Manual o AT&T 235-600-510, Software Analysis Guide o AT&T 235-600-601, Processor Recovery Messages o AT&T 235-900-106, Product Specification 5E6 o AT&T 235-900-107, Product Specification 5E7 o AT&T 235-900-108, Product Specification 5E8. o AT&T 235-900-109, Product Specification 5E9(1). Note: Other manuals not identified previously that can be helpful to the customer are listed in AT&T 235- 000-000, Numerical Index - Division 235. This index is for informational purposes only. Site documents should be ordered from the applicable H- drawing. If you do not have a copy of this index, it can be ordered from the Customer Information Center in Indianapolis, Indiana. The 5ESS(R) switch is supported by many built-in maintenance aids: o Simplified human interface system o System status displays o Combined audible and visual alarm system o Automatic routine testing of circuitry o Routine exercise (REX) capability o Automatic fault detection and recovery o Manual testing capability o Remote maintenance capability o Duplication of common control equipment o Compact physical size. The MCC is the primary communication link between on-site maintenance personnel and the 5ESS switch. The MCC provides the interface capability for administrative and maintenance tasks. The major components of the MCC (Figure .AW G1/) consist of the following: o A video display terminal with keyboard o A receive-only printer (ROP) (optional) o A key telephone set with loudspeaker o A test access unit (TAU). Page displays on the video display terminal provide the status and control information needed to perform maintenance tasks. Maintenance requests are input using the keyboard. The ROP provides a hardcopy of input and output messages. Thus, a record is available for future reference. The key telephone set is used to communicate with work areas outside the office. This telephone set can be used independently of the 5ESS switch, thereby ensuring outside communication if an office outage occurs. A loudspeaker is provided for communication at times when maintenance personnel need the use of both hands. The TAU provides telephone jacks that enable communications with other work areas in the office. In addition, TAU provides access to trunks and lines for maintenance activities. The real-time system status is shown at the MCC video terminal on the second and third lines of the page display. (See Figure .AW G2/.) Thus, the occurrence of any abnormal conditions is displayed immediately. The MCC status display must be valid at all times. This requires monitoring of the time indicator to ensure reliable display indications. The time-of-day indicator (24-hour clock) at the top right of the video display is incremented every 5 seconds. Observation of this time indicator helps to determine if the display interface is operating. If the indicator is not changing, the interface is not working, and the entire video display is invalid. Figure .AW G2/ is an example of the MCC page display design. Whenever an alarm condition occurs, an audible/visual alarm is activated to ensure that maintenance personnel are informed even if the MCC terminal is not being monitored. To make it easier for maintenance personnel to quickly locate off-normal conditions on the video displays, various video attributes such as reverse video, flashing, intensity, and color (optional) are used in addition to text. The particular combination of these attributes depends on the maintenance ``state.'' Refer to Table .AW TAG/ for additional information on the most commonly used MCC states and their video characteristics. When an alarm condition occurs, the severity of the alarm is indicated by the level indicator (CRITICAL, MAJOR, or MINOR) backlighting in the summary status area at the top of each display. Each alarm level (CRIT, MAJ, or MIN) also has its own distinct sound. The unit indicator that represents the particular area of alarm condition (for example, OVERLOAD or BLDG/PWR) flashes until the alarm is retired. To retire the audio/visual alarms, depress the ALM RLS function key. Once the alarm is retired, the level indicator returns to normal video and the unit indicator stops flashing. The alarm level color remains until the MCC page associated with the unit has been displayed. At this point, the unit indicator goes to black on cyan which indicates the problem still exists but is being investigated. When the condition causing the alarm is corrected, the unit indicator returns to normal video. Automatic routine tests are checks and tests run automatically on a prescheduled basis to verify the integrity of a circuit, a unit, or the entire system. The system has built-in self-checks which constantly check parity, framing, and protocol of words and messages. In addition, periodic routine exercises are run. These exercises verify the complete integrity of all units including both the operational and the maintenance-related parts of units. Per-call tests are run on a line every time it is used. Table .AW TB/ provides a list of automatic routine tests, intervals, and functions. Audits are also run to check software programs. Audits are run periodically and during slack call processing periods. The Call Monitor makes test calls for periodic analysis to detect the loss of call processing functionality. The MCC enhances the manual testing capabilities of the system. Diagnostics can be run using the keyword at the MCC to input the appropriate messages. If the appropriate input message is not known, the user can enter the dgn:keyword?, where the keyword for example could be ``luhlsc'' and the symbol ``?'' indicates help when an appropriate input message is desired. Figure .AW G3/ is an example of how the help command can be used. The first help command gives the complete input message, and the second help command gives the options associated with the input message. User's actions are indicated in bold type. In addition, many block diagram-type page displays (that is, MCC page displays -- see Section .RM 4.2/) are available to help in locating and identifying faults. The TAU provides a means of connecting test equipment to various lines and trunks. Direct connection and terminal access jacks are contained in the TAU. Section .RM 3./ contains a description of TAU. The duplication of common control equipment permits switching from a faulty unit which is active to a standby unit. Thus, the faulty unit can be taken out of service (OOS) and repaired without impairing the switching capability of the office. Maintenance of the system can be performed remotely by operational support systems (OSS), located at the remote switching control center (SCC). The MCC human interface capabilities are available at the remote SCC. This includes the video display, input/output, and alarm control capabilities. The trunk and line work station (TLWS) TAU is not provided at the remote SCC. The objective of this maintenance plan is to identify both hardware and software faults in the 5ESS switch before they reach a service-affecting level. If this maintenance plan is followed, customer complaints can be reduced to a minimum and be a useful indication of the switch performance. If customer complaints suddenly increase in a normal office, the complaints can provide information useful in identifying problems and their causes. Therefore, customer complaints can help identify the following: Complaint location: o Switching module (SM) or group of SMs o Remote switching module (RSM) o Line unit (LU) or group of line units. Complaint type: o Plain old telephone service (POTS) o Private branch exchange (PBX) o Features o No dial tone o Call cutoff. Complaint cause: o Software update o Change notice (CN) Application o Unusual office activity o Cable cut o Nondiagnosable hardware fault. If unusual or unresolved conditions and complaints cannot be resolved at the local level, contact your next level of technical support. Until such time as the customer complaint rate is under control, the number of customer complaints received is not an accurate indication of switch performance. A more accurate accounting can be achieved through the monitoring of the operational test failures (OTFs) and the grid fabric failures. ROP Analysis: Periodic checks should be made using the daily reports to determine whether or not hardware faults are occurring. AT&T 235-105-220, Corrective Maintenance Procedures, can be used to identify the hardware involved in the following instances (except for the line removal reports; they are covered in this manual): o Unit diagnostic (routine exercise) failure o Grid fabric failures o OTFs -- Set the verbose mode periodically to allow printing of these messages o Per-call test failures (PCTFs) o Machine detected interoffice irregularities (MDIIs) o Line removals. Action: If any of the previous conditions occur, then go to the appropriate section in this manual for a more complete description and the appropriate action. Note: If you are unable to resolve the errors after referencing the section and documents mentioned, then contact the next level of technical support. ROP Analysis: Periodic checks using AT&T 235-070-100, Traffic and Plant Measurements, Appendix 1 of Administration and Engineering Guidelines, should be made to detect if large numbers of the following types of messages have occurred: o Manual action asserts o Audits o Interrupts [for example, single-process purges (SPP) is a first-level interrupt]. Action: Set the print log status periodically to print these types of messages. Upon receiving a repetition of these, refer to AT&T 235-600-500, Asserts Manual, and AT&T 235-600-400, Audits Manual, for the proper action to take. Note: If you are unable to resolve the errors after referencing the document mentioned, then contact the next level of technical support. Remember, initializations can cause codes 5, 7, 8, etc., customer complaints, so frequently check the ROP for indications of trouble. For more information on initializations, refer to AT&T 235-105-250, System Recovery, which has some general information about system recovery/initialization. Office Backup Methods: There are four levels of backup for the 5ESS switch disk drives. These levels are as follows: a. Memory to primary disk backup b. UNIX(R) Real-Time Reliable (RTR) operating system root partition to backup-root partition backup c. Office dependent data (ODD) backup to tape d. Full office backup to tape. For detailed procedures covering the disk drives, refer to the Memory Allocation Procedures in AT&T 235-105-210. For information on Backup Schedules and Guidelines, refer to Subsection .RM 3.23.7/ in this manual. Program update is the process that activates orderly program changes in the switching equipment software. The changes are made to solve a system problem. The following two types of program updates are available: o Official Fixes: Software updates o Emergency Fixes: Temporary measurement plan (TMP) software updates. In-service offices receive most software fixes via software updates. The following list of operations should be adhered to when applying software updates: 1. In a post-turnover office, when it is not in a retrofit or restart mode, the Operating Telephone Company (OTC) is responsible for obtaining and applying all applicable software updates. 2. Maintain software updates to the current Software Change Administration and Notification System (SCANS) level. 3. Follow the software update's special and soak instructions exactly. In an in-service office, remember to SOAK all software updates for at least a full day. 4. Some software updates require a boot of the administrative module (AM) or a craft initialization in order to make portions work properly; therefore, the application of the software update should be carefully monitored by the Switching Control Center System (SCCS) or site personnel until it is complete. 5. When a software update requires a boot, always perform the boot during a low-traffic period. 6. If a software update fails during application (apply, soak, and/or official), and the situation cannot be resolved, escalate to the next level of technical support. Warning: DO NOT remove files such as ``Cud'' and ``.pupstat,'' or any file in ``/etc/bwm'' without first consulting with Electronic Switching Assistance Center (ESAC), Regional Technical Assistance Center (RTAC), or Customer Technical Support (CTS) Organization. This section represents some preventive maintenance procedures needed to keep the 5ESS switch operating efficiently. The fan filters in the 5ESS switch frames and moving head disks (MHDs) should be checked periodically. A dirty filter will not allow adequate air to circulate within the equipment and could lead to early failure in the hardware. For information regarding replacement frequency and replacement procedures for both frame fans and MHD fans, refer to AT&T 235- 105-210, Routine Operations and Maintenance Procedures. Review the REX output messages daily to see if any failures have occurred. Normally, if a diagnostic failure occurs during REX, that hardware will remain OOS and must be manually diagnosed and restored to service. This is a very important action to conscientiously perform. If one side of a duplex unit fails REX diagnostics, it is not restored. If the other side of this unit takes a fault, there is no way to recover and the unit will be in duplex failure mode. It is easy to see how critical this would be if the unit was important to call processing. Check the ROP Reference Guide section of AT&T 235-105-119, Maintenance Guide Utilizing OMS5, for canceled or needed REORGANIZATION messages. Determine why the relation reorganization failed. If unable to locate the trouble or resolve it, escalate to the next level of technical support. All critical system status indications are provided locally and remotely. The MCC provides real-time system status summary indications, control and display capabilities, and human interface. These capabilities are also remoted to the remote switching control center. System status and alarm indications are displayed on the remote switching control center critical indicator panel. The status display provides a comprehensive presentation of system conditions including the following: o Alarms and other abnormalities o Abnormal load conditions o Significant control in effect o Individual unit status. The status display is made up of abbreviated name displays of each monitored unit or condition. Normal operating conditions are displayed in dynamic (light on dark) text. Trouble conditions are displayed in steady bold reverse video (dark letters on enlarged bright background) or a color combination. All alarm conditions are displayed by a unit indicator such as - AM, SM, and a level indicator - (CRITICAL, MAJOR, or MINOR). An audible indication is also sounded as follows: o In minor alarm conditions, the minor alarm horn sounds (if office is equipped). o For major alarm conditions, the audible alarm chimes at a slow rate. o For critical alarm conditions, the audible alarm chimes at a fast rate. There are two system alarm release modes: automatic alarm release and manual alarm release. If the system is in the automatic alarm release mode, the audible alarm and the flashing alarm conditions are released 5 seconds after initialization. If the system is in the manual alarm release mode, the audible alarm and flashing alarm conditions are released by operating the ALM RLS function key on the video terminal keyboard. Minor audible alarms are retired after 5 seconds in either mode. Released alarms and controls in effect remain in the alarm condition until the system has been restored to normal operating condition. The alarm release mode is changed via a maintenance command available on display Page 105/106, 116, or an input message. Table .AW TC/ lists MCC status indicators and their meanings. Note: A display administration process (DAP) terminal must be used to access the control and display portion of the MCC or remote switching control center video display. The DAP terminal can be used to perform any command that is needed to maintain the switch (for example, poke command 330 on MCC display Page 1240 restores MSGS 0 to service). These terminals are defined in the data base, and a number (office dependent) of DAPs can be assigned. A maximum of eight DAP terminals for 5E6 or sixteen DAP terminals for 5E7 and later can be used simultaneously per switch. Non-DAP terminals enable the user to perform the same functions as DAP terminals except for being able to access and display the MCC page displays. The non-DAP terminals use message mode commands to maintain the switch (for example, input message, RST:MSGS=0). The control and display portion of the MCC or remote switching control center video display is used to monitor at a subsystem level. Control and display consists of many separate pages that can be displayed individually. Each page shows the operating condition and a menu of possible input commands for a particular subsystem. Figure .AW G4/ shows a control and display page. The display conventions used for equipment status are also used for all control and display page displays. An index page is provided to allow quick access to any of the control and display pages during trouble situations. A message page is used whenever control and display information is not required (that is, the display of system status is all that is desired). This avoids confusion, since the display provides only the system status and input message information when the blank page is used. (Figure .AW G2/ shows the video display as it appears with the blank page display.) The input message area is used for inputting human interface messages. Refer to Section .RM 3./ of this document for details of how to use input messages. Any deviation from normal system operating conditions produces a printout on the MCC or remote switching control center. The printout contains all data relevant to the condition, diagnostic results, and a list (by priority) of suspected faulty circuit boards. Periodic traffic and plant summaries are also printed on the printer. All of these printouts are important in determining system status, with diagnostic information and circuit board lists being of primary importance to maintenance personnel. The printer should be connected whenever maintenance is being performed in the office. For detailed analysis of printouts, refer to AT&T 235-600-750, Output Messages Manual. Routine maintenance is performed on a specified schedule to secure maximum performance of the total network. Since peak load periods and features are different from office to office, some tests (for example, REX test) may not have specific test schedules that are best for all of the offices. In this situation, the equipment test list (ETL) can be very helpful in giving references to procedures and recommended time intervals to perform these types of tests. Refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures, for the 5ESS switch routine maintenance schedules (residing in the ETL). More importantly, this manual contains descriptive and detailed procedures for the schedules listed in the ETL. Nonscheduled routine maintenance procedures are basically those procedures that are not listed on the ETL. The following list contains some of the nonscheduled operations: o System Control Functions: a. Loading automatic message accounting (AMA) tapes b. Set/change date and time c. Alarm system assignments. o Call Trace Procedures: a. Nuisance call trace b. Interoffice call trace c. Utility call trace. o Miscellaneous Routine Procedures: a. Bring up AMA teleprocessing system (AMATPS) b. Bring up central trunk test unit (CTTU) c. Bring up Engineering Administration Data Acquisition System (EADAS). o Memory Alteration Procedures: a. Request software update summary b. Obtain ODD backup schedule c. Load software updates from tape. For the complete list of nonscheduled routine operations, refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures. The video display pages are used together with the system status display and ROP output messages to isolate a hardware trouble to a specific unit. Then the system's diagnostic and grid exercise programs are used to pinpoint the trouble to the specific circuit pack(s) as described in Section .RM 2.5.3.2/, Hardware Repair Procedure (following). Also, a simplified trouble location procedure is shown in Figure .AW G5/. Note: Periods of AM insanity may affect MCC display and functional capabilities. Automatic trouble location is an integral part of the diagnostic and grid exercise programs in the 5ESS switch environment. These programs are designed to test functions at the circuit pack (board) level. Therefore, most test failures can pinpoint the fault to a small number of circuit packs. The diagnostic and grid exercise programs maintain a list (by priority) of suspect circuit packs at each test point in the diagnostic. During execution, this list expands and contracts as testing shifts attention among the hardware. Upon the first failure, the current circuit pack list is converted to a suspected faulty equipment list containing location information and printed on the ROP. Combined use of this list and the frame and shelf-mounted designation strips provide direct access to suspect circuit packs. The trouble repair procedures in AT&T 235-105-220, Corrective Maintenance Procedures, should be used to replace the faulty circuit pack. A sample faulty equipment list printout is shown in Figure .AW G6/. For each circuit pack, the following information is given: o AISLE: Aisle equipment frame location within the office. o MODULE: Switching module number. o CABINET: Cabinet type and number. o CODE: Circuit pack number. o FORM: Equipment forms. A form can be one of two types as follows: a. Series number with carrier pack b. Issue number with micro code. o EQL: Equipment physical location [for example, 53-016 (where 53 = vertical distance, in inches, of the circuit above the floor and 016 = horizontal distance of circuit from LEFT edge of bay in 1/8-inch increments)]. A third field [53-016-XX, where XX = depth (in the unit) in 1/10- inch increments] is also included. o TYPE: Helper unit. Note: When a note (for example, 8) appears in this column, refer to the ``TLP (Trouble Locating Process) NOTE APPENDIX'' in AT&T 235-600-750, Output Messages Manual. o DGN: Diagnose. o LUHLSC: Line unit high-level service circuit. Another maintenance tool available to maintenance personnel for locating trouble is the utility call trace. Utility call trace allows users to do the following: o Snapshot the hardware path representing a call connection. o Trace all connections of a call. o Trigger a call trace with a utility break point. o Print the path of the call through the switch in diagnostic format on the ROP and show it on the MCC screen. Craft and/or maintenance personnel can also use utility call trace to trace test calls. For example, to troubleshoot customer complaints, a test call can be traced to or from the customer to see what hardware is in use. In the 5ESS switch, data base inconsistencies can be identified by asserts and audits. The results of the asserts and audits can be sent to the system log file and/or the ROP. Audits and asserts are used in the 5ESS switch to verify and check the validity of software data structures such as the ODD and equipment configuration data (ECD) in the AM. Data base repair procedures are provided in AT&T 235-105-220, Corrective Maintenance Procedures. Reconfiguration is necessary to prevent faulty hardware from affecting system processing. Equipment can be reconfigured either automatically or manually. Basically, reconfiguration consists of the following: o Appointing other hardware to assume functions of the faulty hardware o Removing traffic from the faulty hardware o Removing faulty hardware from service o Updating system status with appropriate alarms, indicators, printouts, etc. Since the 5ESS switch varies in size and equipment usage, the recovery procedures vary in complexity. The large office obviously has a wider range of reconfiguration possibilities since it contains more hardware. Fault recovery is performed at a subsystem level whenever possible. Only the fault-associated subsystem(s) is affected during recovery. When a hardware fault is identified, the system begins automatic recovery procedures. If the system is in good operating condition prior to the fault and the fault is not catastrophic, automatic recovery should restore normal processing. Automatic recovery performs all the reconfiguration and initialization processes necessary to correct the problem. Automatic recovery restores the system in the great majority of all faults. Manual reconfiguration is used in the repair of a unit following automatic recovery or if automatic recovery does not place the faulty unit OOS and restore processing. Most manual reconfiguration is done from the MCC or the remote maintenance center (if provided). There are several numeric input commands on the control and display pages that can be entered from the terminal keyboard. They are as follows: o REMOVE: This series of commands (2XX and 2XXX) reroutes traffic from the affected unit and places the unit OOS. o RESTORE: This series of commands (3XX and 3XXX) diagnoses the unit to determine if it is capable of operating. If diagnostic returns all tests passed (ATP) or conditional all tests passed (CATP), the unit will be restored to service. Otherwise, the unit is left OOS. o SWITCH: This series of commands (4XX and 4XXX) causes all traffic and processing to be switched to the mate controller. o DIAGNOSE: This series of commands (5XX and 5XXX) requests diagnostics to be run on specified unit(s). The unit remains out of service until manual restoral to service is requested. o FORCE: This series of commands (4XX and 4XXX) unconditionally forces operation to the desired unit and puts the mate unit OOS Forced Unavailable. All of these commands are entered conditionally, and the system enables them. The video page display for each unit has a menu of commands (and input codes) available for that unit. If the system is experiencing problems, it may not honor these input requests. Unconditional options and manual overrides are provided for these cases. The amount of direct control available depends on the type of unit involved. Fully duplicated (duplex) units [for example, message switch control unit (MSCU), office network timing complex (ONTC), and module controller/time slot interchanger (MCTSI)] contain control/display (CD) packs with several status light-emitting diodes (LEDs) and manual reconfiguration switches. The CD packs such as the SN412, SN516, and the TN1077 all contain four switches and five LEDs which provide and display the following capabilities: o ON: A momentary pushbutton switch used to power up the unit. o OFF: A momentary pushbutton switch used to power down the unit only if that unit is not in service or is unavailable. o RST/ROS: A rocker switch used to request a unit be restored to service or conditionally removed from service. o MOR: A momentary manual override switch. Whenever this switch is simultaneously depressed with the OFF switch, power is turned off regardless of the hardware state (ACT, STBY, or OOS). o OFF: A red LED that lights whenever unit power is off. o ALM: A red LED that lights whenever there is a power fault on the unit (fuse or converter alarm). Note that in the alarm state, all power may not be off in the unit. Once maintenance personnel power down the unit for repairs, the OFF LED lights and the ALM LED goes off. o OOS: A yellow LED controlled by the system. This LED lights whenever the unit is out of service. o RQIP: A green LED controlled by the system. This LED lights whenever a request to restore or remove a unit from service has been received by the system. If this request is denied or fails, this LED flashes for 5 to 6 seconds. The LED goes off when the requested action has been completed. o ROS: A green LED that lights whenever the restore/request out-of-service (RST/ROS) switch is in the ROS position. Figure .AW G7/ shows an example of the SN412/SN516 CD pack. Table .AW TD/ summarizes duplex control and display pack features for the 5ESS switch. Unduplicated (simplex) units are not equipped with control and display packs. All simplex requests (RST, ROS, etc.) are input via an input message. Simplex status [request in progress (RQIP, OOS, etc.)] is displayed and printed at the MCC or SCC. The AT&T 3B20D computer units are equipped with the TN5 AM C/D pack shown in Figure .AW G8/. This pack is equipped with an additional alarm cutoff/test (ACO/T) LED and switch that the SN412 and SN516 packs do not have. Unit controller conditions must be known at all times. This information is needed to define system status. Four general status states have been defined for the 5ESS switch unit controllers. They are active, standby, out of service, and unavailable. Table .AW TE/ summarizes basic controller states. At times, it is necessary to know how, or why, a controller entered a particular state. A set of state-qualifiers has been developed to further define a controller state. A combination of qualifiers may be required to specifically define a state. Table .AW TF/ shows qualifiers used and sample applications in the 5ESS switch. All duplex subsystems follow the same general methods of manual reconfiguration. Reconfiguration is accomplished by manual inputs at the MCC or remote maintenance center and/or the unit control and display circuit pack. Since simplex units are unique, they cannot be reconfigured as such. Therefore, circuit board replacement is the method of restoring simplex units. The other part of system recovery is initialization. Serious system difficulties may be caused by equipment (hardware) troubles, difficulties in executing the program (software), or by human error. Caution: If the system is failing to process calls properly (is not able to complete test calls, etc.), the system should be automatically attempting to recover itself by taking automatic emergency actions. This should be indicated to office personnel by status indicators, printouts, switching of system controllers, etc. If automatic emergency actions do not restore normal system processing and control, manual emergency actions or system recovery procedures will be required. The distributed processing architecture of the 5ESS switch employs many autonomous processors. The main processing units are the AM, the Communication Module Processor (CMP), and the individual SMs. Initialization can treat these processors both independently and collectively. Therefore, the following four types of initialization have been defined: o AM Initialization: This is an initialization of the AM. o CMP Initialization: This is an initialization of the CMP (added in 5E6). o SM Initialization: This is an initialization of the SM. o System Initialization: This is a complete initialization of the AM, the CMP, and the SMs. Note: Although slightly different actions can take place at each level in the AM, CMP (added in 5E6), and SMs, the overview of the philosophy and objectives of the initializations are the same. The various levels of recovery, their attributes, and recovery time estimates for individual SMs, the CMP, and the AM are explained in Table .AW TG/. In any case, the stimulus of an initialization is the failure of a check that indicates if the integrity of a processor or data base is questionable. Initialization is caused by a signal which is generated when the hardware or software detects an error (resets). It can also be caused by manually inputting initialization requests (interrupts) at the video terminal keyboard. An initialization consists of some or all of the following: o Restoring processor(s) to a good software state o Restoring the periphery to a good software state o Aborting certain activities o Zeroing or setting temporary data to a known good state o Reloading the memory from disk file. Not all of the preceding actions are performed on every initialization. An initialization can be more or less drastic depending on which and how many of the preceding routines are performed. The degree of initialization is determined by the system level count. The level count is incremented each time a recovery attempt fails within a predetermined time lapse. The higher the level count, the more drastic the recovery actions become. After an initialization occurs, an initialization timing interval exists for a short period of time. If no other initializations occur within this time interval, the level count will be reset to zero. For detailed information on initializations and recovery procedures for the 5ESS switch, refer to AT&T 235-105-250, System Recovery. This is the lowest level of software initialization. It is performed automatically in response to audit features, user program defensive check failures (asserts), and restarting from maintenance interrupts. Action associated with this level may be as follows: o Localized initialization of user-owned global data o Scheduling elevated audits o Logging failure information. Control flow is then returned to the previously interrupted point. The single-process purge (SPP) level is used whenever an error is detected which is severe enough to make it unsafe to return to the point of interrupt. The initialization action varies somewhat with the processing environment, but the primary objective is to restore a software configuration that can support resumption of normal processing. In general, the recovery actions associated with an SPP are as follows: o The running process or task is killed and, if essential, reinitialized. o Any global data being used by the process is restored. o Any hardware or software resources are recovered. o Any associated processes are informed. o Control is reestablished at a ``safe point.'' o Failure information is logged. Some recovery may be performed on a deferred basis by audits requested by the purge. In terms of call processing, if the current process is associated with a call, the call will be idled and the subscriber given reorder or dial tone. Wideband calls will be idled if the process is associated with a wideband call. Directed audits are used as an initialization action whenever inconsistencies are discovered in critical data structures such that continued operation is not possible. This level is generally invoked from either an audit or a user program defensive check failure (assert). The action taken is to audit, in an unsegmented mode, enough data to ensure that system operation can resume, and to schedule on a deferred basis any additionally required audit activity. Restart from a directed audit is generally via a single-process purge of the current process. Again, failure information is logged. If the running process was associated with a call, the call will be idled and the subscriber given reorder or dial tone. This is a full initialization of a single AM kernel process. All dynamic nonshared data is initialized or audited. All data shared among known processes is audited. In 5E6 and later software releases, common channel signaling is suspended during this short initialization. A selective initialization (SI) is a high-level initialization (although it is the lowest level processor-wide recovery action). This initialization can be performed automatically due to recovery actions or manually by maintenance personnel. The basic actions of an SI in the various processors are described as follows: o In the AM, an SI includes an unconditional bootstrap for all static text and data for both the UNIX RTR operating system and the 5ESS switch application processes. Then, all dynamic data is either initialized or audited (OOS hardware status and stable calls are preserved). Call processing functions in this processor are suspended during this time interval, but stable calls are preserved. o In the CMP (5E6 and later software releases), an SI does not include any hashsum checks or pumps. All dynamic data is either initialized or audited. Call processing functions are suspended during this interval, but stable calls are preserved. o In the SM, an SI does not include any hashsum checks or pumps. All dynamic data is either initialized or audited, preserving OOS hardware status and most stable calls (certain connections that would appear to be stable are disconnected due to their more complex dynamic data or ongoing message interaction with the switch, that is, 3- and 6-way calls and AP data links). Call processing functions within the initializing processor are suspended during the initialization interval. A manual SM selective initialization with an unconditional full pump is available (though it has additional affects on the SM of longer downtime and, possibly, a few lost stable calls due to the pump use of time slots). Note: Stable calls over SM selective initialization include wideband. Options to back out temporary recent changes and program updates are supplied when pumps are involved in the previous processors. A full initialization (FI) is the highest software level of processor-wide recovery actions. The FI can be performed automatically due to recovery actions or manually by maintenance personnel. There are several types of FI which can be used (for example, power up FI and FI with pump) each of which changes the severity of recovery action. Every FI will initialize hardware at some level even though it is mainly a software initialization. Different hardware levels will be seen depending on the processor being initialized. The basic actions of an FI in the various processors are described as follows: o In the AM, an FI includes an unconditional bootstrap of all static text and data for both UNIX RTR operating system and the 5ESS switch application processes. Then, all dynamic data is initialized. When the AM undergoes an FI, the hardware level selected can cause the loss of stable calls routed through the time multiplexed switch (TMS). During the initialization of the AM, the SMs are supplying dial tone and giving reorder to the customers or processing intra-processor SM calls if the stand-alone option is utilized. In 5E6 and later software releases, call processing will be maintained during an AM FI except at the highest hardware level, which reinitializes the TMS. New CCS calls will be inhibited until the CNI Ring is initialized. o In the CMP (5E6 and later software releases), an FI does not affect stable calls although any transient calls being processed at the time of the FI will be lost. The FI includes a conditional partial pump of any static text or data that fails to pass a hashsum check against a disk copy of the hashsum tables. All dynamic data is initialized. Both manual and automatic full CMP initialization with an unconditional pump can be invoked. o In the SM, an FI includes a conditional partial pump of any static text or data that fails to pass a hashsum check against a disk copy of the hashsum tables. Then, all dynamic data is initialized. Depending on the type of FI, an FI will also be performed on the SM's peripheral hardware and software. Any transient and stable calls being processed by the processor undergoing the full initialization or on connected peripherals will be lost. A manual SM full initialization with an unconditional pump is available. Options to back out temporary recent changes and program updates are supplied on any pump of the various processors. Office bring-up and dead-start situations use a manual system-wide FI (that is, AM, CMP, and all SMs). A postmortem dump is normally printed via the ROP to permit analysis of the cause of the system troubles; however, postmortem dumps can be logged in the postmortem dump log (PMLOG) or the DAYLOG file. The output message class (MSGCLS) is used by the maintenance personnel to specify where the postmortem dumps are to be sent, that is, to the physical device (ROP) or the software device (PMLOG or DAYLOG). Output consists of all data relevant to the trouble, such as the following: o Value of program counter at time of occurrence o Value of latched address and data bus o System process that last had control o Values of internal control registers o Stack area values of last system process o Contents of register area for last system process o Contents of all error registers which indicate the source of the error(s) o Contents of counters used for escalation to higher levels of initialization. An SM postmortem dump is normally sent to the ROP approximately 1 to 5 minutes after the system has gained sanity. The first report to indicate an SM initialization has been started is the high-level initialization report. The first line is as follows: REPT SM=a INITIALIZATION TRIGGER=bb EVENT=cc Refer to AT&T 235-600-750, Output Messages Manual, for details concerning the REPT SM message. Efforts should be made to analyze the cause of the initialization and to verify that the SM recovers properly. When the SM recovers, analyze the postmortem dump and any related error reports. The related reports will have the same event numbers. If the postmortem dump is not printed automatically, it is possible to obtain the postmortem dump by using the input command: OP:POSTMORT,SM=a [,OFL] [,SPP] [,EVENT] [,ESCAL] [,RCVY] [,DCF]; Refer to AT&T 235-600-750, Output Messages Manual, for details concerning the OP:POSTMORT,SM message. The postmortem dump report contains information about type and source of the interrupt that occurred in the SM controller and the resulting level of initialization. This report has two possible formats, the shortest of which is normally printed on the ROP, while the extended version is stored in the log file DAYLOG. The log file DAYLOG is kept in general to locate severe software faults. The contents of the file can be dumped by entering the following message for 5E6 and later software releases: OP:LOG:LG="DAYLOG"[:[DATE=b[&&c],][TIME=d[&&c],][KW="f",][ID=g,] [MSGCLS=l|TYPE=h,][LIMIT=i,][,CLASS=j|,DEVICE="k"]]; Refer to AT&T 235-600-750, Output Messages Manual, for details of this message. The short version of the previously mentioned SM postmortem dump reports has the following format: REPT SM=a,b HWLVL=c SWLVL=d e f g EVENT=h i j-ERR FAILING ADDR=k PROCESS:BG=r,s,t CM=u,v FG=w,x,y z [,TYPE=h] [,LIMT=i] [,CLASS=j|,DEVICE=k]] The extended version from the log file DAYLOG looks as follows: REPT SM=a,b HWLVL=c SWLVL=d EVENT=h i e f g j-ERR FAIL-ADDR=k l-m DATA-BUS=n TIME=o:p.q PROCESS: BG=r,s,t CM=u,v FG=w,x,y z ORIG-HW-STATUS: a : b c d a : b c d FINAL-HW-STATUS: a : b c d a : b c d PREVIOUS TYPE/COUNT: e f SHADOW TYPE/COUNT: g h AUX DATA: m n o p ESCALATION-COUNTS: i j k l Refer to AT&T 235-600-750, Output Messages Manual, for details of the REPT SM message. In addition to the postmortem dump reports, related error reports should be analyzed to locate the fault. Related error reports will have the same event number. Examples of related error reports are illustrated as follows: o INIT SM=a LVL=b SUMMARY EVENT=g ... o INIT SM=a,b LVL=c OSDS-M EVENT=f g o REPT SM=a DLI HW REGS EVENT=g ... o REPT SM=a SP HW REGS EVENT=b ... o REPT SM=a TSI HW REGS EVENT=c ... o REPT SM=a CI b HW REGS EVENT=c ... o REPT SM=a PI b HW REGS EVENT=c ... o REPT SM=a RLI b HW REGS EVENT=c ... o REPT SM=a MC b HW REGS EVENT=c ... Suppressing 5-Minute Automatic Dumps: The input command RLS:POSTMORT,SM=a; (MML format) may be used to suppress the 5- minute automatic dump. The command also clears the postmortem area; otherwise, the area will be cleared automatically 1 hour after the initialization. Error Source of Interrupt: In the report REPT SM=a,b HWLVL=c SWLVL=d e f EVENT=h i, field ``e'' reports hardware subunit which triggered the interrupt, and field `` f '' indicates the source of the error that caused the interrupt (see AT&T 235- 600-750, Output Messages Manual). A CMP postmortem dump contains information about the error(s) that caused the CMP to take recovery action. Information is sent to the ROP, usually within 1 to 5 minutes after the system has gained sanity, and is displayed in several types of output messages beginning as follows: REPT:CMP INIT:CMP REPT CMP= POSTMORT For additional information on these messages, refer to AT&T 235-600-750, Output Messages Manual. If the postmortem dump is not printed automatically, it can be requested via the following input message: OP:POSTMORT,CMP,[EVENT][,RCVY][,DCF]; To suppress the 5-minute automatic dumps, enter the input command beginning as follows: RLS:POSTMORT,CMP=a; For details of both messages, refer to AT&T 235-600-700, Input Messages Manual. Note that the ``RLS'' message ``unlocks'' the area where postmortem area is stored, that is, allows it to be overwritten with information about subsequent postmortems. Otherwise, the system preserves postmortem information for an hour. There may be additional error reports and status dumps that provide more information about the error(s). They will have the same event numbers as the postmortem dumps. Some information is stored in a log file on disk. To display information from the log file, enter the following message: OP:LOG:LG="DAYLOG"[:[DATE=b[&&c],][TIME=d[&&c],][KW="f",][ID=g,] [MSGCLS=l|TYPE=h,][LIMIT=i,][,CLASS=j|,DEVICE="k"]]; For details, refer to AT&T 235-600-700, Input Messages Manual. Try to analyze the cause of the initialization and verify that the CMP recovers properly. Software in the various peripheral controllers of the communication module (CM) produces several types of postmortem dumps. Each is identified by the controller which produced it. All have the following form: REPT:POST MORTEM a EVENTNO=b The peripheral controllers which produce postmortem dumps for both CM1 and CM2 are as follows: o CLNK = Communication Link o MSCU= Message Switch Control Unit o MMP = Module Message Processor o PPC = Peripheral Pump Controller o FPC = Foundation Peripheral Controller o TMS = Time Multiplexed Switch o CMP = Communication Module Processor (for software releases 5E6 and later). The basic format of the postmortem dumps on the units listed previously is as follows: REPT:POST MORTEM a EVENTNO=b cccccccc The variable field definitions are as follows: o a = hardware identity (for example, MSCU=0) o b = decimal number indicating the event number o c = hexadecimal array of eight digits in a sequence of eight words and in four lines. Each of the hardware identities listed previously is explained in detail in AT&T 235-600-750, Output Messages Manual. The postmortem dump report for the TMS hardware identity is an exception to the general format that the other hardware identities follow. The format for TMS is as follows: REPT POST MORTEM DUMP TMS=a EVENTNO=b c c c c c c c c The variable field ``cccccccc'' can appear more than once; however, the most useful information is contained in the first four words. With the various postmortem dump reports, an autonomous dump on the Network Clock is possible. The layout of this report is as follows: DUMP NC a b c NETWORK CLOCK a CCB/CLRT REGISTERS X' dddddddd This message can be used to identify the exact problem according to the bits that are set as shown in the format description. For details of this message, refer to AT&T 235-600-750, Output Messages Manual. Note: Information concerning the register layouts for the registers referred to in the error reports (in the log files) can be obtained from the Appendixes section of AT&T 235-600-750, Output Messages Manual. Two types of interrupts may occur in the AM. These interrupts are indicated by either a REPT CU a ERROR INTERRUPT or a REPT CU a MAINTENANCE INTERRUPT report. When either of these reports are printed on the ROP, more information about the interrupt is written in a log file. The AM uses three error log files: memory history log (MEMLOG), error interrupt handler log (ERLOG), and automatic postmortem log (PMLOG). Entries in the MEMLOG file and the ERLOG file are generated with an REPT CU interrupt report. Entries in the PMLOG file are generated following a system initialization and are accompanied by an REPT CU interrupt report. Each log file entry has a sequence number associated with it. Since all three log files use the same sequence counter, the order in which a set of entries occurs can be determined from the sequence numbers. These numbers appear in the REPT CU interrupt report. Each entry has a date and time stamp to relate log entries to other printouts. Therefore, it is important to save the ROP output of the last 12 hours prior to a REPT CU interrupt report to be able to extract any data that might be useful for error analysis. Memory Error Types: When a MEMLOG report must be analyzed, the type of memory error can be indicated in the report. Descriptions of these errors are as follows. o ERROR A: An OR of internal memory hardware checks resulted in error detection. If this occurs in the active control unit, a stop-and-switch occurs. At least one bit is set in error register 1 (ER1) bits 0-11 or 22. In the trapped address register (TAR), the bits 28 and 29 are both reset. o ERROR B: An out-of-range address is detected. The bits 0-11 and 22 in ER1, plus the bits 28 and 29 of TAR are all reset. o ERROR C: The Hamming check circuitry detected a multibit uncorrectable error during a system access of memory. TAR bit 29 is set. o ERROR D: A correctable data parity of Hamming check error or uncorrectable refresh error is detected (during system access or refresh access). TAR bit 28 is set. Error Interrupts: Normally error interrupts are nonfatal errors, detected by the system in either the on-line or standby control unit. However, they can escalate to a processor switch or an initialization if preset thresholds are exceeded. When an error interrupt occurs, the information printed on the ROP or contained in the log files can be used for error analysis. The log file information should be saved in case the next level of technical support is needed. The error interrupts can be classified into the following three areas: 1. Less serious hardware errors (for example, memory errors, input/output errors, or refresh parity) 2. Errors related to standby CU in a duplex (active/standby) configuration 3. Software-related errors. When error interrupts occur, the associated information is written in one of the following error log files: o MEMLOG o ERLOG. If the REPT CU a ERROR INTERRUPT b c is output, the ``a'' indicates the control unit side 0 or 1; the ``b'' indicates the interrupt type; and the ``c'' indicates the sequence number under which supplementary data is available in the particular log file. Therefore, when log file output is requested, this sequence number should be specified for the parameter ``KW'' in the input command: OP:LOG:LG=a[:DATA,DATE=b[&&c]] [,TIME=d[&&e]] [,KW=f] [,ID=g] [,TYPE=h] [,LIMT=i] [,CLASS=j|,DEVICE=k]]; The variable ``a'' equals the log file name (that is, MEMLOG or ERLOG). Maintenance Interrupts: Maintenance interrupts are output after a system initialization. These reports indicate that a maintenance reset function (MRF) has occurred. The postmortem dump, normally printed automatically or requested via OP:LOG: a message, can be used to determine the problem. The variable ``a'' in this situation equals PMLOG. See AT&T 235-600-750, Output Messages Manual, for details of the OP:LOG: a message. The postmortem dump is used to determine the reason for a particular initialization. The data provided consists of most of the critical hardware registers from both control units and some nonhardware type of information dealing with the past and present configuration of the AM. The start of an initialization is usually indicated by the following reports: o REPT CU a MAINTENANCE INTERRUPT (where a = the member number) o REPT PHASE IN PROGRESS o START OF CU a RECOVERY (where a = the member number). Normally, the first report printed is the START OF CU a RECOVERY report. The MAINTENANCE INTERRUPT indicates the associated log entry in the PMLOG. The AM postmortem dump is subdivided into the following sections: Note: The AM postmortem dump sections are described in AT&T 235-600-750, Output Messages Manual. o Heading: The PMLOG reports are either labeled MAINTENANCE INTERRUPT or POSTMORTEM DUMP. The header POSTMORTEM DUMP will appear in a manually requested initialization and sometimes when the initialization was started due to the application software. o Initialization message: This section indicates the source of initialization, the on-line processor at the time of initialization, the processor actually involved in the initialization, and the recovery action that took place. Also, the source of the request is indicated (by the SOURCE field): hardware, software, or manually requested. Note, this source does not indicate the problem source. o Requested initialization parameters. o EAI buffer. o Timer. o General registers. o Faulty CU registers. o Interrupt stack saved state. o Off-line registers. o Main store registers. o Real-time clock. The faulty control unit registers, timers, and the main store registers are primarily of interest when the initialization is a hardware request. When the initialization is software requested, the requested initialization parameters and the general registers are of interest. The initialization message should be analyzed for both types of initialization. Postmortem Analysis: When a postmortem dump is generated, the response would be a REPT CU a MAINTENANCE INTERRUPT b report, where ``b'' indicates the sequence number belonging to the postmortem dump entry in the PMLOG file. When not printed, the postmortem dump can be requested via the OP:LOG:LG="PMLOG",KW=a; (a = the sequence number). Refer to AT&T 235-600-700, Input Messages Manual, for details of the OP:LOG message. The Operating Service Position System (OSPS) maintenance is provided by AM software, switching module processor (SMP) software, and firmware located in the link adapter unit (LAU), the video display terminal (VDT), the basic services terminal (BST), and the combined services terminal (CST). The OSPS maintenance, through software in the areas of system initialization (SI) and recovery, terminal maintenance (TM), and the human/machine interface, support OSPS maintenance in the following areas: o OSPS operator positions (VDTs, BSTs, and CSTs) o Data links [Directory Assistance System/Computer (DAS/C), Real-Time Rating System (RTRS), etc.] o Remote alarms o Miscellaneous OSPS features [automatic charge quotation (AUTOQUOTE), busy line verify (BLV), etc.]. Refer to the following manuals when performing OSPS maintenance: o AT&T 250-505-100, OSPS Description and Procedures o AT&T 250-505-11X, OSPS Maintenance and Growth (X = manual number associated to the applicable software release) o AT&T 250-520-100, OSPS Directory Assistance/Listing Services Basic Services Terminal, Description and Operation o AT&T 250-520-105, OSPS Toll and Assistance Video Display Terminal, Description and Operation o AT&T 250-520-110, OSPS Combined Services Terminal, Description and Operation. Refer to AT&T 235-001-001, Documentation Description and Ordering Guide, for the complete list of OSPS manuals. The 235-XXX-XXX manuals do not provide maintenance procedures for the repair of equipment manufactured by vendors other than AT&T (for example, tape drives and disk drives). To identify the appropriate maintenance manual for each unit of such vendor equipment, refer to Section 3 of AT&T 235-001-001, Documentation Description and Ordering Guide. The objective of this section is to provide a working knowledge of LU architecture, necessary to understand and resolve complex LU problems. Note: This subsection contains only the introductory information concerning LU problems. Refer to AT&T 235-105-220, Corrective Maintenance Procedures, for the procedures needed to resolve the LU failures. Currently there are three types of 5ESS switch analog LU in use. These LUs are referred to as the Model 1 LU, the Model 2 LU, and the Model 3 LU. The Model 1 LU is a 2-shelf unit and, when fully equipped, it contains 48 circuit packs and two (-48 V to 5 V) DC power converters. The Model 1 LU grids contain three circuit packs each. The Model 2 LU is also a 2-shelf unit and, when fully equipped, contains 38 circuit packs and two (-48 V to 5 V) DC power converters. The Model 2 LU grids contain two circuit packs each. The Model 3 LU is a 2-shelf unit. When Model 3 is fully equipped, it contains 40 circuit packs and two DC power converters. The Model 3 LU consists of 10 grids. Each grid consists of two circuit packs. The Model 1, Model 2, and Model 3 LUs are fused identically. At the power distribution bay, one 20-amp fuse for each LU is used to provide -48 V DC power to the SM cabinet local fuse panel. Twelve 70-type fuses, at the local fuse panel, are assigned to distribute -48 V to each LU. The LU is a peripheral unit and is located in the SM. Up to eight LUs may be assigned to one SM. The most important function that an LU has to perform is to connect an analog subscriber line to the 5ESS switch. To accomplish this, the line must be connected to a channel. The analog voice then is converted to pulse code modulation (PCM) digital data, and the PCM digital data is then put on a peripheral time slot. One fully equipped LU: o Model 1 or Model 2: Has the capability of serving 512 subscribers o Model 3: Has the capability of serving 640 subscribers. With 64 peripheral time slots available to each LU: o Model 1 or Model 2: Has a ratio of 512 lines to 64 time slots, or a concentration ratio of 8:1. o Model 3: Has a ratio of 640 lines to 64 time slots, or a concentration ratio of 10:1. Any condition that causes an LU service group to be removed from service, also causes the line to channel concentration ratio of that LU to be changed (for example, in a Model 2 LU, it changes from 8:1 to 16:1). This will usually result in slow dial tone, no dial tone, or incoming calls going to recorder. To avoid customer complaints, it is recommended that LU service groups not be removed from service during heavy traffic hours. If a service group is forced OOS automatically, by peripheral fault recovery, it should be treated as a service-affecting condition and repaired and restored to service as soon as possible. Each LU is controlled by a peripheral interface control bus (PICB). Also, each LU is connected to a peripheral interface data bus (PIDB). The PIDB is used to send and receive PCM digital voice time slots, between the LU and the time slot interchanger (TSI). Each LU is assigned a total of 64 peripheral voice time slots, 32 time slots for each service group. There are also 32 channels in each LU service group. The 64 LU channels are dedicated to the 64 PIDB time slots. Each LU grid services 64 subscribers. When a grid in the Model 1 LU is removed from service, 64 subscribers are removed from service. The grid in Model 2 and Model 3 LUs can be removed from service at the half-grid level. When a Model 2 or Model 3 LU half grid is removed from service, 32 subscribers are removed from service. Any LU grid OOS condition is service affecting and should be resolved as soon as possible. See AT&T 235-105-220, Corrective Maintenance Procedures, for details on restoring OOS grids to service. The LU A-LINKs are wired paths between the first and second stage switches in LU grids. If an A-LINK is OOS, a path is not available through the concentrator grid network. An accumulation of OOS A-LINKs can cause network blockage and can be service affecting. To avoid subscriber complaints, OOS A- LINKs should be restored to service as soon as possible. See AT&T 235-105-220, Corrective Maintenance Procedures, for details on restoring OOS A-LINKs to service. The LU hardware is not duplicated. If an LU function is out of service, that function is unavailable for call processing. If operational test failures (OTFs) are occurring or REX grid fabric exerciser failures are being reported, the affected LU is being forced to complete calls with defective hardware. This can be service affecting and a source of subscriber complaints. A grid fabric exerciser fault in the grid of LU Model 1 or halfgrid of LU Models 2 or 3 changes its MCC display state to degraded (DGR). In summary, restore OOS hardware to service as soon as possible. Take action to resolve operational test failures and grid fabric exercise faults. Refer to AT&T 235-105-220, Corrective Maintenance Procedures, for assistance in resolving LU faults. Any LU fault that cannot be resolved at the local level should be supported by the next level of technical support. The terminal maintenance subsystem is designed to detect faults in lines, trunks, and associated equipment. Fault detection is performed either automatically or manually by software controlled tests. Testing is performed locally by utilizing the TLWS capabilities. Remote testing can be implemented from centralized test systems such as the following: o Local Test Desk (LTD) o Mechanized Loop Test (MLT) o Remote maintenance center, for example, SCCS o Centralized Automatic Reporting on Trunks (CAROT) System o Centralized Trunk Test Unit (CTTU). These remote test positions have powerful testing capabilities to supplement the local TLWS. Per-call testing by call processing software is a primary means of line fault detection. A number of these tests are performed on every call processed by the 5ESS switch. Per-call tests are performed independently on both the originating and terminating sides of the call. In addition, tests are done at one of three phases of a normal call. These are as follows: a. Origination: Origination is the interval between the calling party off-hook detection and talking path connection. b. Termination: Termination is the interval from when the called party line is determined to be idle to when one of the following occurs: o Calling customer goes on-hook o A talking path connection is broken down. c. Disconnect: Disconnect is the interval between customer on-hook and line restoration to idle. When a per-call test detects a failure, all data associated with the call is sent to terminal maintenance for a test failure that indicates a trouble on the line. Trouble indications within the line unit are referred to switch maintenance. The problem is then analyzed, and a decision is made on what course of action is to be taken. This could result in any of several maintenance actions such as diagnostic tests, changing equipment status states, or a system alarm. Routine tests are periodic maintenance checks run by the terminal maintenance subsystem. These tests are used to assure trunk and line integrity. Routine tests are run on circuits that are assumed to be in good operating condition. These tests can be initiated either automatically or manually. Flexible scheduling of automatic trunk testing is possible through automatic progression testing (APT). In APT, a test history keeps track of information concerning the tests. This allows interruptions of the testing cycle when the trunks are needed for service. When traffic subsides, the testing resumes where it left off. Test results are analyzed and displayed locally and/or at a remote testing location. Routine trunk tests can be classified as operational or transmission tests. Operational testing of trunks encompasses the following objectives: o Verify the operational characteristics of interface and carrier facilities and distant central office equipment. o Verify the end-to-end ability to detect and send signaling and supervision. o Routinely exercise the interface circuits in a distant central office. A trunk error analysis (TERA) analyzes MDIIs that result from trunk or universal tone decoder failures. The results (pass or fail) of trunk operational tests are also routed to TERA. When TERA determines that a trunk or universal tone decoder is experiencing a high-error rate, recovery actions are initiated. The recovery actions can consist of an output message, or, when applicable, an operational test on an outgoing trunk. Refer to AT&T 235-105-119, Maintenance Guide Utilizing OMS5, for details of how to use TERA. For information about the activation of TERA, refer to the appropriate RC manual (AT&T 235-118-XXX, where XXX = manual number associated to the applicable software release. See AT&T 235-000-000, Numerical Index -- Division 235 and Associated Documents, for specific manual numbers) that contains the RC symbolic view name RC_TERA. The 5ESS switch supports incoming test calls for operational tests. The operational test for lines is the automatic line insulation test (ALIT). The ALIT is an automatic test system that scans lines and identifies faults before they affect normal service. Many tests and functions are provided to aid in trunk and line testing. These include the standard test line (TL) and functions used in previous switching systems. The routine test facilities provided include the following: o 100TL (Balance) o 101TL (Communication) o 102TL (Milliwatt) o 103TL (Signal supervisory) o 104TL (Transmission measuring and noise checking) o 105TL (Automatic transmission test line) o Synchronous test line o Nonsynchronous test line o Permanent-busy test line o Touch-tone dialing test line o Open circuit test line. The per-call tests (lines only) are as follows: a. Origination of calling party: o False cross and ground test o Power cross o Continuity check. b. Termination of called party: o False cross and ground test o Power cross o 20-Hz ringing current o Loop resistance to detect pretrip o Continuity check. c. Disconnect: o Restore verify. The Call Monitor provides an early detection mechanism for loss of call processing functionality when all other system indicators appear normal. The Call Monitor reports to the craft by ROP and an alarm indicator on MISC Page 116 when a failure in call completion analysis occurs. The ROP output is in the form of a REPT CALLMON 5- or 15-minute report. The ROP output message has either a major, minor, or no alarm. The failure criteria is defined as follows: o For the 5-minute report, failure occurs if more than 50 percent of the total calls attempted in a 5-minute period are not passed. o For the 15-minute report, failure occurs if more than 90 percent of the total calls attempted in a 15-minute period are not passed. The major alarm criteria is defined as follows: o For the 5-minute report, a major alarm occurs if 40 percent or more of the total tests are ``operational test failures.'' o For the 15-minute report, a major alarm occurs if 50 percent or more of the total tests are ``operational test failures.'' The minor alarm criteria is defined as follows: o For both the 5- and 15-minute reports, a minor alarm occurs if 70 percent or more of the total tests are ``indeterminate'' plus ``not attempted'' failures. If no alarm criteria is met, no alarm will be printed with either analysis report. The Call Monitor will perform separate analyses for common channel signaling (CCS) test calls (if equipped) along with non-CCS test calls. It utilizes the Terminal Maintenance APT functionality to make these operational test calls. Non-CCS test calls are based on the default APT test for the trunk group in the AM ODD. All CCS test calls use the Voice Path Assurance (VPA) continuity test. For 5E9(1) and later, ability to inhibit the Call Monitor on a per-trunk-group basis is provided by a new field in the static AM ODD relation RT_TRKG. The new field, ``callmon_inh'', is populated from recent change trunk view 5.1 (as is the existing field for inhibiting APT). If APT is inhibited, then the Call Monitor must be inhibited. The monitor routinely cycles through the AM ODD for trunk groups and selects trunk groups to use for making the test calls. A test call will be attempted every 30 seconds. The monitor can be inhibited as well as requested to print the past 15-minute history and print per-test call results (verbose mode). The alarm indicator on MISC Page 116 can also be retired. Additional information on the Call Monitor is provided in Sections .RM 3./ and .RM 4.2/ of this document and in AT&T 235-105-210, Routine Operations and Maintenance Procedures. Recent change (RC) is a system function that allows maintenance personnel access to the 5ESS switch data base. Recent change is used to add to or delete from the data base. Also, recent change is used to update or verify the data base using a select/mask format. The data base for the 5ESS switch supports a relational data base with the following methods of access: o Recent change/verify (RC/V) o Office data administration (ODA) o Office record programs (called views because they are user-oriented) o Remote memory administration system (RMAS). For details concerning the recent change and verify subsystem, refer to Section .RM 3.10/ of this manual. Field update is the process of activating orderly program changes in the 5ESS switch software. In-service offices receive most official software changes in the form of software updates. The software update originates as a program enhancement or as a fix for a problem within the software release. Function, file, and byte replacement are the three types of software updates provided. The 5ESS switch software updates usually replace entire sections of program software as compared to the word-by- word changes of other Electronic Switching Systems. Aiding in the updating of a 5ESS switch are three external interfaces to the program update subsystem. These three interfaces provide for the generation, distribution, and activation of software updates. The interfaces are as follows: o A Programmer Support System (PSS) o A SCANS o Remote maintenance center (for example, SCCS). The PSS originates program updates via the generation and initial distribution of software updates. After a software update has been composed, tested, and approved at the PSS, it is assigned a software update identification number and transmitted to SCANS. In an emergency (such as SCANS outage), a software update could be transmitted from the PSS over a data link directly to the office if the situation requires immediate action to maintain switching system integrity. Craft and/or maintenance personnel at the remote SCC or 5ESS switch would have to make a verbal request to the program update coordinator at the PSS. The coordinator would set up the emergency data link (from the PSS to the 5ESS switch) and manually transmit the software update, after maintenance personnel primes the 5ESS switch for reception of the software update files. The SCANS is an AT&T time-shared computer system for distributing software updates. It is usually accessed by maintenance personnel at the remote SCC work station using the No. 2 remote SCC computer to receive and record the software updates. The SCANS can also be accessed by maintenance personnel at the local office. The SCANS should be checked prior to inserting or activating any software updates to ensure that they have not been canceled or changed. The remote SCC provides for remote activation of software updates at a 5ESS switch. It uses a 1200-baud dial-up terminal to access SCANS and activates the program update subsystem to apply the software update. Communication between the remote SCC and the program update subsystem is via the maintenance channel. It is not necessary to have maintenance personnel present at the local office to aid in the activation of the software update(s). Although software updates are usually activated by the remote switching control center, they may also be activated locally through the MCC video terminal for one or more of the following reasons: a. The remote SCC option is not carried by the 5ESS switch being accessed. b. The remote SCC (if the option is carried) is down, and a software update must be activated to maintain switching integrity. Note: Reasons (a) and (b) require that a 1200-baud terminal be present at the 5ESS switch. The terminal must be full duplex, be capable of printing at least 80 characters per line, and must have a 212A-type data set. This terminal is used to access SCANS and poll the SCANS data base for relevant software updates. c. Local control of the software update activation is desired. This carries the following two options: 1. The entire activation procedure (including access of SCANS) is to be done locally. 2. The remote SCC accesses SCANS and turns control of the activation over to local personnel at the MCC. The software update activation responsibility between AT&T and a switch owner (normally an OTC) is as follows: a. During preturnover (new office), retrofit, and restart intervals, the AT&T installer is responsible for obtaining and activating all current software updates in the SCANS data base which apply to that office. b. At all other times, in a working office (when not in a retrofit or restart mode), the switch owner or the remote switching control center is responsible for obtaining and implementing all applicable software updates. Regular field updates are done in a timely and orderly fashion through software updates. Unexpected problems with the software release can occur that require immediate correction, not allowing time for the normal software update development and issue processes. Emergency fixes are accomplished on a word- by-word basis under direction of the AT&T Customer Technical Support (CTS) Organization. Emergency fixes are assigned a sequential craft number similar to the software update number. The program update subsystem provides emergency fixes with the same status and options as software updates (that is, make temporary, make permanent, backout). Emergency fixes specify the address to be changed, the new data to be inserted, and the old data to be matched. Emergency fixes are also known as address-data couplets. As with software updates, most emergency fixes are activated remotely from the remote SCC. Communication between the remote and local program update subsystem is via the maintenance channel. It is not necessary to have maintenance personnel present at the local office to aid in the activation of the fix. Emergency fixes may also be activated locally through the MCC if the following occurs: a. The 5ESS switch does not carry the remote SCC option. b. The remote SCC (if the option is carried) is down, and the fix must be activated to maintain switching system integrity. c. Local control of the fix is desired. Software release retrofit refers to the software and procedures used to replace the resident software release text and data bases [ECD, ODD, and System Generation (SG)] in an operational 5ESS switch with new software release text and evolved data bases. Software release update refers to the software and procedures used to replace the resident software release text in an operational 5ESS switch. Software release update allows for replacement of text for installation of a software update (formerly BWM) consolidation load or a software point load release. Software release update does not include evolution and replacement of the SG or ODD data bases. Although there is no ECD evolution, the application of point load specific keystroke files to the ECD is allowed. Large terminal growth (LTG) refers to the software and procedures used to add large quantities of lines and trunks to an operational 5ESS switch by evolution and replacement of the ODD data base. It does not include replacement of the software release text, ECD, or SG data bases. Software release retrofit, software release update, and LTG are referred to collectively as software release transitions. New software release text and data bases are delivered to the office on magnetic tapes supplied by AT&T. Recent change activity should be kept to a minimum or stopped, if possible, for 2 weeks prior to a software release retrofit or LTG. Prior to all transitions, a copy of the existing software release should be saved on spare disk packs or magnetic tapes. In some cases, associated hardware and/or read-only memory (ROM) circuit pack changes may be required prior to starting the transition process. When the transition process begins, however, all essential duplex and simplex equipment must be operational. Although stable 2-port circuit-switched calls are saved over a software release transition initialization, a software release transition should be planned for a low-traffic period to minimize the number of calls that might be affected by call processing interruptions. The types of calls not saved during a software release transition initialization include calls involving more than two ports, such as calls using conference circuits. Transient calls (that is, originating, dialing, ringing, calls on hold, calls being forwarded/transferred, etc.), packet calls, and test calls are also not saved. For detailed information concerning software release retrofit procedures, refer to AT&T 235-105-24X (X = manual number associated with applicable software release). For detailed information concerning software release update procedures, refer to AT&T 235-105-34X (X = manual number associated with applicable software release). For detailed information concerning LTG procedures, refer to AT&T 235-105-44X (X = manual number associated with applicable software release). For additional information, refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents. Note: The Design Change Management System (DCMS) data base is not restricted to only covering the CNs for the 5ESS switch. This data base provides CN coverage for all of the AT&T Network Systems products. The DCMS data base is the official vehicle for notification of product changes (that is, CNs) for all of the AT&T Network System products. Also, this data base notifies the customer of service enhancements that can be purchased. The DCMS data base service is free to the customers. The following information concerning CNs is provided to the customer by DCMS: 1. DOCUMENTATION on the changes that are made to AT&T Network Systems products. Documentation is in the form of a product change notice (PCN). A PCN is issued for each change. The PCN document consists of the following: a. Product being changed b. Reason for the change c. Description of the change d. Effect that the change will have on the customer's operations during implementation e. Affected product drawings and their titles f. A comparison of the markings that the product will bear before and after the change g. Other miscellaneous information. 2. APPLICATION STATUS REPORTS that track and report on the status of the implementation of these changes in the offices that employ affected products. Application status reports are compiled interactively. The reports illustrate the current status of the offices that are affected by product changes. The status reports can be obtained in a standard format or can be customized on an ad hoc basis to meet the DCMS user's specific needs. 3. HISTORICAL INFORMATION by CN, office, or product once the implementation process has been completed. Historical information is available on an ad hoc basis. The DCMS data base covers CN office implementations made by an AT&T installation group from 1983 to the present date. The DCMS user's manual explains how to use the menu driven DCMS data base. The manual is distributed by the National CN Engineering Group located at the AT&T Southwestern Region. With a proper ID number and login, customers can obtain an on-line version of the manual. For additional information, call the telephone number shown in the address for Southwestern Region as follows: AT&T Southwestern Region Department NF93D6T00 1111 Woods Mill Road Ballwin, Missouri 63011 (314) 891-2930 The DAP terminal can be used to perform all commands/functions that are needed to maintain the switch. A maximum of 8 DAP terminals for 5E6 or 16 for 5E7 and later can be accessed. These terminals are defined in the data base. The master control center (MCC), trunk and line work station (TLWS) (TLWS is mode of MCC), supplementary TLWS [with the exception of being able to access the emergency action interface (EAI) page display] are DAP-type terminals. Non-DAP terminals can be used to perform the same functions that the DAP terminals perform with the exception of being able to access the MCC page displays. When using a non-DAP terminal, input messages (message function mode) must be entered to maintain the switch. No input commands (for example, poke commands) can be entered from a non-DAP terminal. The MCC uses four function keys. When one of these keys (Figure .AW G9/) is depressed, the system performs the corresponding function. The keys are as follows: o ALM RLS: Alarm release o CMD/MSG: Input command or input message o NORM DISP: Normal display o EA DISP: Emergency action display [can only be performed from the MCC or switching control center (SCC)]. When the system is in the manual retire mode, the ALM RLS function key releases audible and visual alarm indications (CRITICAL, MAJOR, or MINOR, and flashing indicators). Flashing indicators go to steady reverse video when retired. Note: The minor alarm audible is self-releasing after 5 seconds, but its visual indication must be released manually. The command/message (CMD/MSG) function key configures the MCC to accept either input CMDs or input MSGs. The key acts as a toggle and allows input in one mode or the other. The user may switch between either mode after acknowledgment of the previously entered message. Any unexecuted data in either area is lost if a switch is made before an acknowledgment is received. Unexecuted data in the input message area is normally saved until an intercharacter time-out occurs. If a time-out occurs before the message is completed, all data is lost. The position of the cursor on the video display indicates which input mode the MCC is in. The cursor resides in the input message line area while in the MSG mode. If the MCC is in the CMD mode, the cursor resides at the CMD entry area (at the top left of the control and display area). Whenever the display is brought on-line or a new page is selected, the input mode will remain unchanged. The NORM DISP function key places a page controlled from the administrative module (AM) on the display. The page displayed will be the previously displayed page. Depressing the NORM DISP key again will redraw a clean display without aborting any processes in progress. The EA DISP function key enables emergency action mode and displays the EAI page on the screen. This page is used during a system emergency for system recovery functions. Depressing the EA DISP function key again will abort all incompletely entered actions and redraw the emergency action interface page display. Note: The emergency action mode can only be enabled from the MCC or SCC. Most other keyboard keys are used in a normal fashion to enter numeric codes, input messages, and alphanumeric responses to the system. Their input is respective to the symbol designated on the key. Certain keys are used for line administration as explained in the remainder of this section. The following procedure may be used to access an MCC page display: 1. Select a normal system display page by depressing the NORM DISP function key. 2. If the maintenance terminal is not in the command mode, depress the CMD MSG function key. Note: When in the command mode, the CMD:_ prompt is displayed and the cursor is positioned in the command input area in the upper left-hand portion of the display. 3. Enter the desired MCC page number (for example, 100 - Page Index display) that is to be displayed. A capability is provided to specify in their equipment configuration data base (ECD) getty forms the page that is to be displayed automatically on each display device following a terminal restore (for example, initialization, system boot, or remove/restore). The process that initializes a page specified in the ECD must be connected to a port. Therefore, not every page in the system can be displayed automatically following a terminal restore. The following list contains the page names and port numbers of the system pages that may be specified in an ECD getty form: Pagename Portid CPDP 17 INDEX 17 CDUP 17 For applications not desiring a specific display upon a terminal restore, the common processor display page (CPDP) is the default page for the maintenance terminals. If another system page is requested and displayed, depressing the NORM DISP function key causes the last page requested to be displayed again. The following procedure can be used to specify the initial page for a display device. 1. At the maintenance terminal, invoke RC/V by entering 199. 2. Fill in the necessary information to initiate an update of the getty form for the desired display device. Procedures for updating data base forms are explained in the ECD/SG Data Base Manuals [for example, AT&T 235-600-306 for 5E6, AT&T 235-600-307 for 5E7, AT&T 235-600-308 for 5E8, and AT&T 235-600-309 for 5E9(1)]. 3. When the getty form is displayed, enter the name of the initial page desired in the pagename field and the port number of the process that initializes the page in the portid field. 4. After updating the getty form, remove and restore the device for which the getty form was updated. One of the following methods can be used to switch one or more switchable devices [that is, the receive-only printer (ROP) and/or maintenance terminal] to an alternate peripheral controller: a. Input message SW:PORTSW, refer to the AT&T 235-600-700 for details. Note: The port switch must be in the AUTO position. b. Poke input command (401 - PORTSW, 402 - ROP, or 403 - MCRT) illustrated on the 111/112 - AM, AM Peripherals page display. Note: The port switch must be in the AUTO position. c. Flip the port switch associated with the switchable device to either 0 or 1. (0 = peripheral controller 0, 1 = peripheral controller 1). Note: In either of these two positions, the port switch cannot be reconfigured using the previous two methods. The MCC provides the ability to select a control and display page at any time. The index display is brought into the control and display area by entering 100 (into the CMD entry area) and executing it. The 100 index page consists of a list of possible MCC control and display pages. Those pages not shown are requested by entry from other pages in a meaningful hierarchy relationship. Then, the needed page can be selected by entering the page identifier in the command area and executing it. The 100 index page does not list the per-SM pages. The 1000 page is the index into the per-SM pages. Also, any one of the SM-related display pages can be accessed from any page display. For example, to reach the status display of SM 24, you would enter 1010,24, 1190,24, 1800,24, or 141. It is possible to enter a page identifier in the command (CMD) entry area if the appropriate page identifiers are known. The page index display can be used to determine the appropriate page identifier. A display page can be selected by entering its unique 3-, 4-, or 6-digit identifier. All display page commands begin with the number 1. For example, 100 is the INDEX display. Identifiers 105 through 116 are directly related to the SUMMARY STATUS AREA indicators. The page number for the page can be derived from the physical position of the indicator. For example, BLDG/PWR is the fifth summary status indicator; its display page is 105. The SM is the fourteenth indicator; its associated page is 114. As was noted earlier, the system emergency page, corresponding to the SYS EMER indicator, is to be displayed by depressing the EA DISP function key. Page displays are not provided for alarm-level indicators. Other pages are assigned the remaining identifiers grouped on a functional basis, where possible. Whenever the MCC terminal is brought on-line from an off-line state, the terminal will display the identification line, the status summary indicators, the emergency action page, and the input message entry area. The time-of-day indicator should be checked immediately to determine display validity. Options are provided on the maintenance terminal to turn the terminal features on or off. To set these options, see the user's guide for the specific type of terminal being used. Set the options (if available) as listed in Figure .AW G10/. Options are provided on the ROP to turn the terminal features on or off. To set these options, see the user's guide for the specific type of terminal being used. Set the options (if available) as listed in Figure .AW G11/: Note: Systems equipped with the TELETYPE(R) 5310 teleprinter and related equipment have the capability of suspending output to the ROP temporarily. Pressing the BREAK key on the printer will suspend output for 2 minutes or until the BREAK key is pressed again, whichever occurs first. The HERE IS key will do the same. Maintenance commands provided on the MCC displays are entered via numeric codes. The desired code(s) is found in the control and display page menu listing of possible input commands. Any command to be entered must be selected from a list currently displayed or be a page selection command. The input sequence is as follows: 1. Make sure the MCC is in CMD input mode. 2. Find code of desired command on the display. 3. Enter correct numeric code using the semicolon (;) to execute input commands or messages. 4. Execute by depressing either of the following: a. ; (semicolon) b. ENTER key c. RETURN key. The system acknowledges the input request. Section .RM 3.12/, H0W TO USE INPUT/OUTPUT MESSAGES, explains system responses to input messages. The primary function of the EAI is to provide manual recovery capabilities during periods of system emergency. This interface enables configuring a working system when normal recovery procedures prove inadequate. The emergency page has a menu of control and initialization functions that can be forced on the system. Each function is defined and input by a 2-digit command code. The codes are shown with their associated functions on the display. These functions can be used to do the following: o Recover from duplex-processor failures o Disable the sanity timer o Disable hardware checks o Boot the system from other devices. The conventions used for displaying data and selecting functions are similar to those used by other control and display pages. Due to the crucial functions provided, maintenance personnel must be familiar with these commands and their use. Note: There is a sequence of EAI commands that can reduce downtime during periods of system emergency. This command sequence, the 42!9!54 and 42!9!50 pokes, will execute a full office initialization (FOI) with full pump of the SMs and CMPs (5E6 and later) in two parts. The 42!9!54 poke must be entered first and will cause a full initialization of the AM, including CNI Ring (if equipped) and CMPs. When the AM has completed the initialization process, the 42!9!50 poke must be entered next within 30 minutes of the entry of the 42!9!54. The 42!9!50 poke will perform a full initialization with full pump of all SMs sequentially by SM type. If the 42!9!50 poke is entered before the 42!9!54 or after the 30-minute window, the initialization of the SMs will not occur. Refer to AT&T 235-105- 250, System Recovery, for detailed procedures on the use of this poke sequence and for information and procedures on other FOI variations. An in-progress FOI can be cancelled by executing pokes 42!q!50 or 42!Q!50. The execution of these pokes will result in the cancellation of the SMs marked for full initialization with or without pump. The pending initialization of one or more SMs can be cancelled by input command INIT:SM=a[&&b],NOINIT;. See AT&T 235-600-700, Input Messages Manual, for additional information on this command. The EAI circuit pack in the AM must be a TN983. The TN983 circuit pack is located in equipment location (EQL) 102 in the input/output processor (IOP) Basic Unit Shelf located in the processor control cabinet (PCC). The TN983 provides the capability to store the last application parameter used for a recovery action. Note: If a TN83B circuit pack (used in 5E3 and earlier) is currently equipped in EQL 102, provisions must be made to replace this circuit pack with the TN983. The EA DISP function key on the MCC keyboard is used to display the emergency action page. When the EA DISP function key is depressed, it will bring the emergency action page into the control and display area of MCC. This page is available for selection at all times. Note: When the system emergency action page is present on the MCC, the only way to remove it is to depress the NORM DISP function key on the MCC keyboard. Depressing the EA DISP function key again will clear unexecuted input actions and redraw the emergency action display page. After requesting the emergency action display page, the video terminal digit indicator must be checked to ensure a valid display. The video terminal indicator is located in the upper center portion of the display (Figure .AW G12/). The video terminal digit indicator consists of the maintenance teletypewriter (MTTY) or maintenance cathode ray tube/terminal (MCRT) followed by a numeric digit displayed in dynamic text. The digit is incremented every 2 seconds by the peripheral controller (PC). If this indicator is not displayed and is not incrementing, the entire display is invalid. Once the validity of the display is determined, other indicators are used to qualify EAI and emergency functions. Table .AW TH/ summarizes these indicators. Note: The rest of the indicators on the display are valid only for EAIs indicating all seems well (ASW). The EAI indicators reflect the progress of the emergency action. The emergency action is progressing successfully if the ASW indication is present (Figure .AW G12/). The control unit (CU) status area is located at the upper left portion of the EAI page display (Figure .AW G12/). This area informs the maintenance personnel which of the CUs is active and which is on- or off-line. The term CU refers to the control unit or the processor of the AM. At the upper right portion of the EAI page display is the processor recovery message (PRM) area (Figure .AW G12/). The PRMs display the systems coded failure/success recovery information. The PRMs change continuously during an initialization, reflecting the current state. Emergency functions are entered by typing the appropriate 2- digit command code and executing it. Table .AW TI/ provides a list of the EAI commands with a description of their actions. For more details of how to use these functions, refer to AT&T 235-105- 250, System Recovery. The carriage return is used to execute emergency functions. The menu commands can be grouped into the following three categories: o Commands 10 through 15: These commands have a direct and immediate effect on the system. Some commands force the AM into a particular configuration and some release a forced configuration. o Commands 20 through 43: These commands are preparation commands that specify certain conditions prior to a system initialization. These conditions do not take effect until an initialization command is given. o Commands 50 through 56: These are the initialization commands. These commands cause the conditions that were specified previously with commands 20 through 43 to take effect. The severity of the initialization increases with the command number (command 54 has the greatest impact). The system can automatically trigger commands 50 through 53 during an initialization. Command 54 can only be triggered manually and causes an AM and a possible CM initialization. This takes these processors completely off-line, and call processing is disabled for a short period of time. Commands 55 and 56 are normally required during the initial installation interval or when an initialization from tape is required due to a massive corruption of disk data. During this tape load, the system is off-line and call processing is disabled for a considerable period of time. The 51 through 56 commands when entered on the command line cause the system to immediately enter an emergency action mode. Once the emergency action has completed, the system is restored (automatically) to a stable state and call processing resumes. The EAI page display disappears and the MCC Page Display 111/112, AM Peripherals, is automatically displayed. Commands from the EAI page display should only be used under the direction of your technical assistance group. Improper use of the commands on the EAI page can have a very negative impact on the integrity of the system. Each command executed is acknowledged either OK or NG. This acknowledgment appears adjacent to the command entry area in the top left line of the display. After entering a command, the input and response are displayed until the next character is typed. Errors may be erased a character at a time by pressing the backspace key or by pressing CTRL h. The STLWS terminal is a DAP-type terminal which means maintenance personnel can perform the same functions or commands from the STLWS that can be performed from the MCC (with the exception of being able to access the EAI page display). Refer to Section .RM 3.1.1/ for additional information on DAP. The trunk and line work station (TLWS) is an interactive menu interface used to test, monitor, or measure trunks and lines. The TLWS is a mode of the MCC or STLWS and has either eight (5E8 and earlier) or 32 [5E9(1) and later] software controlled test positions. The test positions are used to access other menu pages which are used to perform the actual testing. The other menu pages display information needed to perform TLWS operations. One TLWS terminal can utilize all test positions. The status of test positions may be checked from the Test Position Summary page (5E8 and earlier) or Test Position Summary Screen pages [5E9(1) and later] to determine which test positions are in use and which ones are available. The basic equipment used for trunk/line testing includes the following: o A video display terminal o A key telephone set with a speaker o A test access unit o A ROP. Following are some of the operations that may be performed using the TLWS: o Controlling lines and trunks being tested o Monitoring a short circuit o Measuring/sending frequencies o Making continuous metallic measurements o Providing remove or restore commands used for testing. The basic input sequence for starting a test procedure in the menu mode is as follows: o Make sure the STLWS is in CMD input mode. o Find command of desired test in the task selection display area. o Enter correct numeric code plus additional information (if required). o Execute by depressing the return key. The TLWS is used to test lines and trunks, make measurements, and monitor calls. This testing can be done in either the menu mode or the command mode. There are five basic steps in trunk and line testing. They are as follows: o Seize/access a test position o Seize line or trunk o Perform one or more tests o Release line or trunk o Release test position. Note: Only individual trunks can be seized and tested. Wideband test calls are not supported. The TLWS software feature provides access to a menu-type interactive test system and (in 5E9(1) and later) MML input commands which allow a user to select a trunk or line for testing and to choose the type of test to be performed on the item selected. These functions, as well as that of performing the actual tests, are conducted at test positions. For 5E8 and earlier software releases, eight test positions (numbered 1 through 8) are available for test purposes. For 5E9(1) and later, 32 test positions (numbered 1 through 32) are available. Associated with each test position are the resources commonly used to test 5ESS(R) switch terminations. The test position resources are separated into two groups as follows: o Directly associated resources: These resources are directly associated with the test position throughout its use and are those that are commonly used in testing. Directly associated resources include the talk and monitor (T&M) phone, 101 test line callback access, and the alternating current (AC) and direct current (DC) jack terminations. o As needed resources: These resources are associated with the test position on an as-needed basis during testing. This group includes the directly connected test unit (DCTU), the transmission test facility (TTF), and the integrated services test facility (ISTF). For 5E8 and earlier software releases, the set of resources associated with a test position is determined by the device ID (devid) of the computer terminal being used to perform the testing. The association is performed by matching the terminal's device ID to the device ID key of the RLtlwsr tuple in the ODD. In 5E9(1) and later software releases, the capability is provided to allow the user to choose the set of resources to be directly associated with the test position for the duration of testing. The arrangement implemented by this capability creates a pool of usable resource sets (RLtlwsr relations) from which the user chooses one of the sets and assigns it to the test position. The assignment is made when the test position is seized by either command SET:WSPOS[,TP=X][,ID=Y]; or poke 161,X[,Y] and the RLtlwsr tuple ID is entered (by default or manually) as the value for Y. (In both commands, X = TP number and Y = the RLtlwsr tuple ID.) The set of resources chosen is associated with that particular test position until the position is released. For 5E8 and earlier, the status of all 8 test positions is shown on Page 160, Test Position Summary, a single page. Effective with the 5E9(1) software release, Page 160 is revised and renamed Test Position Status Summary. The revised Page 160 lists the 32 test positions for 5E9(1) along with the ID for each. Also included on revised Page 160 is command 160,Z (where Z = screen number) that is used to display the four Test Position Summary Screen pages (Pages 160,1, 160,2, 160,3, and 160,4). The Summary Screen pages show status information for the 32 test positions. Each page shows status for eight test positions: Page 160,1 for test positions 1-8, Page 160,2 for test positions 9-16, Page 160,3 for test positions 17-24, and 160,4 for test positions 25-32. To display Page 160, Test Position Summary (5E8 and earlier) or Test Position Status Summary [5E9(1) and later], enter command 160. For 5E9(1) and later, enter command 160,Z from Page 160 to display the desired Test Position Summary Screen page. Examples of Page 160 for 5E8 and earlier and Page 160,2 for 5E9(1) and later are shown in Figures .AW G13/ and .AW G15/, respectively. Once a test position is seized, the line or trunk data for that test position will be displayed in the status box of the Test Position Summary page or appropriate Test Position Summary Screen page. The status box contains the following information for each test position: o Test position number o TLWS location o Identification field (TLWS number) o Line/trunk data (DN/TKGMN) o Test type (or test access) o T&M phone status. The absence of data in the status box for a particular test position indicates that the test position has not been seized and is available for use. When a command is entered at the keyboard, it will be displayed to the right of the CMD: symbol located in the upper left portion of the screen on Page 160 and the other TLWS pages. Figure .AW G13/ is an example of Page 160 for 5E8 and earlier which shows the status box and the eight test positions. The absence of status information indicates that all test positions are available for use. Figure .AW G14/ is an example of Page 160 for 5E9(1) and later which shows the 32 test positions and associated Test Position Summary Screens. In this example, ID information appears for test positions 5 and 17 indicating that these positions are not available. Also shown are the commands to select and release a test position and the command to display a specific Test Position Summary Screen page. Figure .AW G15/ is an example of Test Position Summary Screen 160,2 for 5E9(1) and later which shows the status box for test positions 9 through 16. The absence of status information indicates that these test positions are available for use. Any test position shown as available on Pages 160 or 160,Z may be seized by a user. In 5E8 and earlier, the command used to seize a test position is 16X (where X = TP number). In 5E9(1) and later, MML input command SET:WSPOS[,TP=X][,ID=Y]; or poke 161,X[,Y] (where X = TP number and Y = the RLtlwsr tuple ID) may be used. If all test positions are in use, it will be necessary to try again later. All the test positions can be used at the same time. Note: When a test position is requested and the value for option Y is not specified, a default value for that terminal is entered. If the default is null, an error message is output. The user must then request the test position with the RLtlwsr tuple ID (Y value) specified, or the test position will not be seized. When a test position is seized in 5E8 and earlier software releases, task selection Page 4000,X, SEIZE LINE/TRUNK/INCOMING CALL, is automatically displayed. In 5E9(1) and later, Page 8000, TASK SELECTION, is displayed from which a user selects Page 4000,X. At this point, the next action is to seize a line or trunk. Page 4000,X lists the different types of seizure commands for both lines and trunks. In 5E8 and earlier software releases, these commands are located in the lower left area of the page in the task command area. In 5E9(1) and later, the task command area occupies the entire left side of the page. Test results are then displayed in the response area of the TLWS page Figures .AW G16/ and .AW G17/ show examples of the command and response areas. (See Table .AW TJ/ for the page numbers that are associated with the particular software release used in the switch.) In 5E8 and earlier, the major categories of tests that can be performed using the TLWS are displayed on each individual task selection (menu) page. In 5E9(1) and later, the major test categories are shown on Page 8000, Task Selection, a new page for 5E9(1). The individual menu pages list the possible tests that may be performed along with the command to execute that test. The task selection/menu pages all have the same basic format (see Figures .AW G16/ and .AW G17/). The section of the task selection/menu page that contains the commands used to perform tests is different for trunks and lines. Table .AW TJ/ contains a list of all available task selection/menu pages. Note: Task selections 9200 on Page 9000 (5E8 and earlier) and 9200 and 9201 on Page 9000,1 [5E9(1) and later] support testing of digital subscriber lines and customer premises equipment (CPE) for the integrated services digital network (ISDN). Figure .AW G16/ shows the TLWS page layout for 5E8 and earlier software releases and identifies the areas where certain information appears. The major test categories appear on this version of the page. (The specific tests and their commands have been omitted for simplification.) Figure .AW G17/ shows the TLWS page layout for 5E9(1) and later and identifies the areas where certain information appears. The major test categories do not appear on the 5E9(1) version. (The specific tests and their commands have been omitted for simplification.) After seizing a line or trunk and displaying a task selection/menu page, the user can choose the type of test to execute. The status/response messages of the task selection pages will be updated as the test is executed. When the test has finished running a message, the results of the test will be displayed in the response area block. If any problems have been encountered during the test, a related error message will be displayed on the error message line. This test is to monitor a trunk using the menu mode. The following is a step-by-step example of how to monitor a trunk. 1. While in the menu mode of the MCC or STLWS, enter menu command 160 to access the TLWS test system. Response: In 5E8 and earlier, the Test Position Summary page is displayed showing available test positions and the status of other test positions. In 5E9(1) and later, the Test Position Status Summary page is displayed. This page lists the 32 test positions and provides the 160,Z command that can be used to display availability and status information for the test positions. Where: Z = Screen number (160,1, 160,2, 160,3, or 160,4) 2. Enter menu command 16X (5E8 and earlier) or 161,X[,Y] [5E9(1) and later] to seize a test position. Where: X = Test position number. Note: The 4000 series commands are automatically displayed after seizing a test position. 3. To display the list of commands for transmission-type test, enter menu command 5000; or to skip task selection Page 5000, enter menu command 4301 and connect the talk and monitor phone to the seized trunk. Response: MONITOR is backlighted in the response block of Page 5000, and T&M telephone set rings. 4. Take T&M phone off-hook and listen for conversation, off- hook, or some type of suspected trouble. 5. Take appropriate action per local practice. 6. If no further testing will be performed on the trunk, enter menu command 4999 to release the seized trunk. 7. When all TLWS testing is completed, for 5E8 and earlier, enter menu command 20X on MCC Page 160 to release the test position. For 5E9(1) and later, enter menu command 201,X on MCC Pages 160 or 160,Z to release the test position. Where: X = Test position number and Z = screen number. 8. STOP. You have completed this test. If there is a problem that keeps the test from completing correctly, an error message will be displayed on the screen in one of the special fields provided for error messages. There are also messages which explain what kept the test from running correctly. The message will usually be printed on the error message line which is above the status block. Information related to an error may also be displayed in the response area or on the command/action line. The command/action line displays the command being executed, the test position number, and the action that is taking place. The command is displayed in a command mode format. For a complete description of each error message, see the TLWS Appendix or TLWS Progress and Error Reports Appendix in AT&T 235-600-750, Output Messages Manual. After the test is finished and no more tests are to be done on the seized line or trunk, it should be released. To release the line or trunk, enter 4999. The line or trunk may also be released by releasing the test position. There is a default time limit on the release of a line or trunk. If there are no actions on a seized line or trunk for 5 minutes, it will automatically be released. The last thing to do when a test session is over is to release the test position(s) used. In 5E8 and earlier software releases, a test position can only be released from Page 160. In 5E9(1) and later software releases, a test position can be released from Page 160 or from any of the four Page 160,Z pages. To release a test position, return to Page 160 or Page 160,Z by entering 160 or 160,Z, as appropriate. In 5E8 and earlier, release the test position by entering 20X. In 5E9(1) and later, release the test position by entering 201,X. Where: X = Test position number to be released and Z = screen number. At this point, the test session is over. Note: When a test position is left idle for 1 hour, the test position is automatically released. There are two types of trunk tests: interactive and noninteractive. The noninteractive test always does the same thing, and the maintenance personnel has no control over the test. The interactive trunk test requires manual action from the maintenance personnel to control the test. Usually, the maintenance personnel on each end of the trunk run a series of interactive tests to resolve the problem(s). Note: Trunk tests are performed on a single-trunk basis. Wideband test calls are not supported. Transmission Test Calls Test equipment is required at both the incoming and outgoing ends for implementing transmission test calls. The actual measured results are compared against the normal required characteristics for a particular type trunk being tested. The following transmission test calls are provided on the system: o 100 o 101 o 102 o 104 o 105. Operational Test Calls Operational test calls provide a pass/fail indication rather than a measured value. All the tests except Code Answer Test Line (CATL) only need test equipment at the outgoing side of the test call. A predefined sequence of signaling events and tones are used to test the trunk at the outgoing side of the test. The following operational test calls are provided on the system: o Permanent-busy o Synchronous o Nonsynchronous o 103-type test line o CATL-AAD2 or ATEMA. Loopback Test Calls The Digital Service Unit-2 (DSU2) Integrated Services Test Function (ISTF) peripheral provides a digital-circuit transmit and loopback capability to test digital trunks. The transmit service sends an outgoing test signal and, through the use of a digital loopback, receives back test data. The loopback service takes bits (test signal) from the input channel and places them on the output channel either directly [noninverting (LBK)] or with their polarity changed [inverting (LBKINV)]. Effective with a software update in the 5E8 software release time frame, the time slot interchanger (TSI) in 5E6 and later offices also can be used for LBK. The ISTF is still used for LBKINV. Note: The LBK test line for ISDN trunking meets the functional requirements announced in the ANSI(R) standard T1.206-1988 (Digital Exchanges and PBXs - Digital Circuit Loopback Test Line). The ANSI standard designates the test line as a 108-type test line. The 5ESS switch 108-type test line deviates in one minor detail from the ANSI standard in that time- out is currently fixed at 1 hour (in the event the caller fails to disconnect), whereas the ANSI specification calls for a time-out period that can be set by the operating company. Procedures for implementing the 108-type test line capabilities of ISTF are documented in AT&T 235-105-210, Routine Operations and Maintenance Procedures. The following loopback test calls are provided on the system: o LBK/108-type test line o LBKINV. Following are descriptions of the transmission test calls: o 100 - Balance: The incoming side sends a 1004-Hz tone at 0 dBm for 5.5 seconds followed by a quiet termination. The outgoing side does a 1-way loss and noise measurement of the trunk with the tone. o 101 - Communication: The outgoing side calls the number of the T&M phone in another office. At the incoming side, the T&M phone will ring and be connected to the trunk under test. Testing can then be completed. Note: The T&M is not supported for wideband calls. o 102 - Milliwatt: The incoming side sends a 1004-Hz tone at 0 dBm and the outgoing side does a 1-way loss measurement test. o 104 - Transmission Measuring and Noise Checking: Provides a test termination for 2-way loss and 2-way noise. The outgoing side sends a 1004-Hz tone, and the incoming side measures the loss and noise. Then the incoming side sends a 1004-Hz tone, and the outgoing side measures the loss and noise. o 105 - Automatic Transmission Measuring Test Line: Provides far-end access to a responder and permits 2-way loss and noise measurements to be made on trunks from a near-end office equipped with a Remote Office Test Line (ROTL) and responder. Following are descriptions of the operational test calls: o Permanent-Busy: The incoming side sends a busy signal. o Synchronous: The outgoing side sends at least one complete cycle but less than three cycles of audible ringing followed by a silent interval. The incoming side sends OFF-HOOK/ON-HOOK transitions. o Nonsynchronous: This test is similar to the synchronous test but runs faster because it is a less exhaustive test. o 103-type Test Line: This test provides a connection to a supervisory and signaling test circuit for overall testing of these features on intertoll trunks (equipped with ring forward features) which can be reached by an automatic trunk test frame or by dialing manually. o CATL - AAD2 or ATEMA: The incoming side returns 0 to 3 complete cycles of audible ringing and a tone while the outgoing side detects the tone. Following are descriptions of LBK/108-type test line and LBKINV test calls: o LBK/108-type test line: The LBK test line provides a dialable, 4-wire test line capability that accepts binary signals (bits) and loops back received octets (eight bits) from a digital circuit to test digital carrier voice and data trunk facilities. o LBKINV: The operation of the LBKINV test line is the same as that of the LBK except that the polarity of each bit is changed in the loopback service. For example, an input bit that is a ``1'' is placed on the output channel as a ``0''. Note: Loopback tests are supported on a single-trunk basis. Wideband test calls are not supported. The following manual trunk testing features are available at the TLWS: o Seize/release a trunk o Test trunk using T&M phone o Send OFF-HOOK/ON-HOOK o Manually set up call o Monitor a busy port o Connect trunk to a AC/DC jack o Connect trunk to transmission test facility (TTF) o Remove trunks Caution: If a digital facility interface (DFI) is unconditionally removed, the unit will be taken out of service (OOS) along with all of the voice/signaling trunks associated with that DFI. o Restore trunks Caution: If a DFI is OOS and a restoral command for a trunk (associated with that DFI) is issued before the DFI restoral command, audits will show inconsistencies between the hardware status of the DFI and the port status of the trunk. o Get status of trunks o Seize incoming call (101 test) o Perform transmission test o Perform operational test o Perform loopback/108-type test line tests. The automatic progression testing (APT) runs operational tests and code answer test line (CATL) tests on trunks on a specified schedule. The APT tests can determine only if the test passed or failed, not the actual measured characteristics of the trunk. If a trunk fails a test, the test will be repeated; and if it fails again, it will be placed OOS. However, if an excessive number of trunks are OOS, the trunk will remain in service. Note: The APT is disabled in a 5ESS(R) switch for AUTOPLEX(R) System 1000. The APT has the following ten parameters which may be programmed: o The starting time in hours o The starting time in minutes o The length of time for test to run o Each of the 7 days of the week. The automatic trunk test scheduler (ATTS) is used primarily for automatic trunk testing in a 5ESS switch for AUTOPLEX System 1000. (The ATTS is a secured feature that can be purchased independently for use in regular 5ESS switch applications.) The ATTS feature provides the ability to schedule routine testing on a periodic basis and is capable of supporting multiple, independent schedules of test sessions. Features of the ATTS include the following: o Programmable scheduling of tests including ability to add, modify, and delete test sessions o Automatic logging of test results o Optional real-time printing of test results o Report generation o Flexible test session control such as skipping, linking, etc. Refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures, for additional information on ATTS and procedures for its use. Maintenance personnel may also be allowed to enter administrative functions using input messages. Emergency situations may make it necessary for a trunk or group of trunks to be removed from service. A trunk may also be manually placed back in service under certain conditions regardless of its status. Conditional and unconditional removals on trunks involved in wideband calls operate the same as for trunks involved in DS0 calls. The following administrative functions are provided by the TLWS: o Removing trunks from service o Restoring trunks to service o Unconditionally replacing failed trunks to service o Requesting trunk status. The testing, operations, provisioning, and administration system (TOPAS) is an operation support system developed to provide centralized trunk maintenance and administration for trunks terminating on 5ESS switch -- ``toll configurations'' in the AT&T Communications network. The TOPAS and 5ESS switch capabilities are as follows: o Preservice testing, trouble isolation, and repair verification via remote measurement system - digital 3 (RMS-D3). o Current status of all trunks on the 5ESS switch through trunk state change reports from the 5ESS switch and periodic audits. o Direct facility failure reports from the 5ESS switch to facility administrative surveillance system (FAST). Basically, this feature provides the craft at TOPAS with a set of TTY input and output messages that enables communication with the 5ESS switch to perform trunk maintenance. These operational trunk tests can be initiated as follows: o Manually via the input messages TST:TRK or TST:WSAUTO and the TLWS poke commands on menu page 5400,2. The TST:TRK input message can be used to request automatic operational or transmission tests on individual trunks, a range of trunks in a trunk group, or an entire trunk group. Refer to AT&T 235-600-700, Input Messages Manual, for details. If the test type and directory number are omitted from the TST:TRK message, the default values (obtained in the Automatic Trunk Test Table) are used to implement the test. The TST:WSAUTO input message can be used to perform TLWS automatic tests through the menu interface. The trunk being tested must have been seized via the CONN:WSLINE, CONN:WSTRK, or CONN:WSIC input message. The specified test position must have previously been selected with the SET:WSPOS input message. Refer to AT&T 235-600-700, Input Messages Manual, for details of these messages. o Automatically via the trunk error analysis (TERA) or automatic progression test (APT) capabilities. When TERA or APT initiates a trunk test, the default test type and trunk group number are obtained from the Automatic Trunk Test Table. The Automatic Trunk Test Table contains the default test type and trunk group number for each trunk group. For details of this feature, refer to AT&T 235-190-115, Local and Toll System Features. The RMS-D3 is a microprocessor based system providing message trunk testing and maintenance of digital and analog switched circuits. The testing of switched circuits via RMS-D3 is controlled by TOPAS. The 5ESS switch hardware interface to RMS-D3 consists of a control link (X.25 level 3) and a T1 interface. The commands from RMS-D3 as well as responses transmitted by the 5ESS switch utilize the control link. The T1 interface provides access to the RMS-D3 test ports. The 5ESS switch provides the following capabilities for RMS-D3: o Route 104, 105, 109, and 606 calls to RMS-D3 ports. o Route 101 test position calls from RMS-D3 ports and reroute them to the TLWS if these ports are busy. o Ability to originate test calls from RMS-D3 -- test call with outpulsing or without outpulsing, signaling test access with outpulsing or without outpulsing, monitor connection, split talk access, and out-tandem connection. o Mapping of trunk groups and test position numbers, RMS-D3 test access trunks and test position numbers, TOPAS test position number and status (attended/unattended). o Ability to reconfigure RMS-D3 test access trunks to meet testing needs during any given time. For details of this feature, refer to AT&T 235-190-115, Local and Toll System Features. The Call Monitor allows for the early detection of loss of call processing when all other system indicators appear normal. It requires a global digital service unit (GDSU) equipped with TTF responder circuits. The Call Monitor also requires ISTF hardware for performing digital loopback test calls. The Call Monitor reports to the craft by ROP and an alarm indicator on MISC Page 116 when a failure in call completion analysis occurs. The ROP output is in the form of a REPT CALLMON 5- or 15-minute report. The ROP output message has either a major, minor, or no alarm. The failure criteria are defined as follows: o For the 5-minute report, failure occurs if more than 50 percent of the total calls attempted in a 5-minute period are not passed. o For the 15-minute report, failure occurs if more than 90 percent of the total calls attempted in a 15-minute period are not passed. The major alarm criteria are defined as follows: o For the 5-minute report, a major alarm occurs if 40 percent or more of the total tests are ``operational test failures.'' o For the 15-minute report, a major alarm occurs if 50 percent or more of the total tests are ``operational test failures.'' The minor alarm criteria are defined as follows: o For both the 5- and 15-minute reports, a minor alarm occurs if 70 percent or more of the total tests are ``indeterminate'' plus ``not attempted'' failures. If no alarm criteria are met, no alarm is printed with either analysis report. The body of the REPT CALLMON message is as follows: ********************************************************************** REPT CALLMON CURRENT [5 or 15] MINUTE REPORT CALLMON PRINTMODE = [NORMAL or VERBOSE] CALLMON STATE = ALLOWED NON-CCS TEST CALL COMPLETION SUMMARY PASSED FAILED INDETERMINATE NOT-ATTEMPTED LAST-TRKG-PASSED a b c d e CCS TEST CALL COMPLETION SUMMARY PASSED FAILED INDETERMINATE NOT-ATTEMPTED LAST-TRKG-PASSED f g h i j TOP FIVE HIGHRUNNER FAILURE TYPES FAILURE-CODE NUMBER-OF-OCCURRENCES H'k l H'm n H'o p H'q r H's t ********************************************************************** where the lowercase letters are decimal numbers (except for failure codes which are in hexadecimal). The range of valid trunk group decimal numbers in the data base is 0 - 2001. The monitor uses the decimal value 2002 (values e and j in the previous message example) to indicate that no trunk group has passed a test call since the last time the monitor was initialized. The Call Monitor performs separate analyses for common channel signaling (CCS) test calls (if equipped) along with non-CCS test calls. It utilizes the terminal maintenance (TM) APT functionality to make these operational test calls. Non-CCS test calls are based on the default APT test for the trunk group in the AM ODD relations RT_TRKG and TM_ATTT. All CCS test calls use the voice path assurance (VPA) continuity test. For 5E9(1) and later, ability to inhibit the Call Monitor on a per-trunk-group basis is provided by a new field in the static AM ODD relation RT_TRKG. The new field, ``callmon_inh'', is populated from recent change trunk view 5.1 (as is the existing field for inhibiting APT). If APT is inhibited, then the Call Monitor must be inhibited. Note: APT is disabled in a 5ESS(R)-2000 switch for AUTOPLEX System 1000. The monitor routinely cycles through the AM ODD relation RT_TRKG and selects trunk groups to use for making the test calls. A test call is attempted every 30 seconds unless CCS is equipped, in which case two test calls (non-CCS and CCS) are attempted. It is recommended that telephone company personnel set up their APT schedule to allow testing on at least one trunk group from each possible SM. This maximizes the benefit from this feature. The monitor keeps an ever changing list of possible trunk groups to select from in case it does not find a testable trunk group at the 30-second entry as it continues to step through the ODD. This guarantees that the monitor always has a trunk to test. The monitor can be inhibited or requested to print the past 15- minute history and the per-test call results (verbose mode). The CALL MONITOR indicator on MISC Page 116 shows whether the Call Monitor is inhibited or allowed. Entering command 601 from this page generates the message INH:CALLMON which inhibits the call monitor from making test calls and performing call completion analyses. This also clears the monitor's history data. Command 701 generates the message ALW:CALLMON which allows the monitor to start the cycle of making test calls and performing call completion analyses. Command 801 generates the message RTR:CALLMON,ALARM which retires the alarm indicator in the Call Monitor box. Command 901 generates the message OP:CALLMON which prints the OP CALLMON message on the ROP. The body of the message is identical to the REPT CALLMON message except for the first line which is as follows: M OP CALLMON PAST 15 MINUTE REPORT The verbose mode may be entered by typing SET:CALLMON,VERBOSE. The per-test call results is printed in the form of a REPT CALLMON message. The body of the verbose-mode message is as follows: ********************************************************************** REPT CALLMON VERBOSE TEST CALL SM = a PORT = b TRUNK GROUP = c MEMBER = d SIGNALING TYPE = e TEST TYPE = f RESULT = g RETURN CODE = h ********************************************************************** where a, c, d, e, and f are decimal numbers, b and h are hexadecimal numbers, and g is a character string. To clear the verbose mode, enter CLR:CALLMON,VERBOSE. In the event the REPT CALLMON CURRENT [5 or 15] MINUTE REPORT message is printed, the data to analyze is the call completion summary. The failure indicates a less than expected call completion percentage (50 percent in the current 5 minutes or 90 percent in the current 15 minutes). The number of ``failed'' tests is of most importance because this indicates a possible call processing, hardware, or network problem. The CCS data (if equipped) should be compared with non-CCS data to determine if a common problem exists or if the problem is related only to CCS. The OP:CALLMON input message (poke 901 on MCC Page 116) can be typed to compare the past 15 minutes worth of data. Also, the ``LAST_TRKG-PASSED'' field indicates the last trunk group to pass a test call. If the number 2002 appears in the field, no tests have passed since the monitor was last initialized. A manual trunk test can be performed on this trunk group. Note: The Call Monitor reports failures if the AM, CMP, CNI, or critical SM(s) undergo recoveries or initializations. If failures are caused by ``indeterminate'' or ``not-attempted'' calls, the high-runner failure codes can indicate the reason for the problem. Because of the nature of the Call Monitor's interface with TM APT, it is possible that the failures are TM related; meaning that the front-end setup of a test call could have failed due to one of many reasons. This results in no idle trunk member being hunted and verbose output messages printing the null value for SM (0), port (0), and member (4096). In these cases, the monitor should not be interpreted as having detected a loss of call processing functionality. This is the reason for variable alarm levels. Following are typical reasons for indeterminate failures: o TM ABORT: These types of errors occur if TM times out waiting for a message, TM is interrupted while waiting for a message, a route failure occurs when routing for a logical test port (LTP), or an invalid state is encountered. o TM INTERNAL: This error can occur when TM fails to send the route request for the test equipment. o BAD TEST RESULT: Internal program error. Following are typical reasons for not attempted failures: o RESOURCE: These types of errors occur if TM cannot route to the LTP due to busy or reorder, TTF hardware is out of service or unavailable, test equipment failure, inability to allocate tone decoder, failure to reserve equipment, or other equipment allocation errors. o BAD DATA: The ODD related to APT may be invalid. o DSIG OFF NORMAL: Direct signaling capability is unavailable (for CCS). o TSIG OFF NORMAL: Trunk signaling capability is unavailable (for CCS). o CNI INIT IN PROGRESS: The CNI initialization is in progress. If it is determined that failure reports are TM in nature, inspect the GDSU status on MCC Page 110X,Y (where X is the GDSU number and Y is the SM number). Make sure the TTFCOM circuits are in service and pass diagnostics. If they are in service, turn on the verbose mode to identify specific trunk groups that are failing and perform a manual operational trunk test, TST:TRK,TKGMN-x-y, (where x is the trunk group number and y is any valid in-service/idle member found in the ODD). The TST:TRK operation gives additional details as to the exact problem, whether it be TM or call processing related. Other reasons for operational test failures include trip failure, pre-trip failure, activation failure, plain old telephone service (POTS) glare, outpulse failure, and high and dry. For CCS-related operational test failures, refer to AT&T 235-190-120, Common Channel Signaling Service Features. Under certain circumstances, the Call Monitor skips test calls which are not counted as part of the 5- and 15-minute analysis. These fall under the category of ``no test'' when monitored under verbose mode and include the following: o AM MIN MODE: The AM is in Min Mode. o ASSERT: Internal Assert failure. o CNI MIN MODE: The CNI is in Min Mode. o NO IN-SERVICE IDLE MEMBER FOUND: Trunk under test is OOS (automatic or manual) or all busy. Operational test failures are the most severe problem and may indicate a true call processing, hardware, or network problem. If the number of ``failures'' is the reason for the alarmed report, analyze the high-runner failure types and turn on the verbose mode to identify specific trunk groups. A manual operational trunk test can then be performed to obtain additional information. For details on interpreting the input and output messages used with the Call Monitor feature, refer to AT&T 235-600-700, Input Messages Manual, and AT&T 235-600-750, Output Messages Manual. There are two types of line tests: interactive and noninteractive. The only noninteractive test done is the line insulation test (LIT). The LIT can be run automatically or manually. This test uses metallic access to do the measurements and does not actually place a call on the line. All other line tests are interactive tests and are initiated either locally or remotely. Deferred maintenance for the LU A-Links is provided which allows the switch to operate normally with a few A-links OOS. The SET:ALINK a b c d e DEFR input message places the A-link into the OOS deferred state (see AT&T 235-600-700, Input Messages Manual, for details). Maintenance activity can be scheduled at a more convenient time. Following are some of the manual line tests available from the TLWS: o Seize/release a line o Send receiver off-hook tone o Ring the line under test o Monitor busy port o Connect a line to a DC jack o Connect a line to an AC jack o Connect a line to the TTF o Connect a circuit to the 101 test line o Perform a line insulation test o Remove/restore lines (ports) o Get the status of lines. Some of the operations available through the TTF are as follows: o Measure noise o Measure level o Measure broadband o Measure echo return-loss o Measure singing return-loss o Measure singing return-loss high o Send tones at specific level and frequency o Apply open termination o Apply quiet termination. Some of the operations available through the DSU2 ISTF loopback/108-type test line are as follows: o Provide ISTF loopback terminations o Send a pseudo-random bit pattern o Receive and monitor a pseudo-random bit pattern. Effective with the 5E8 software release, a user can measure the integrity of digital data being transmitted on BRI lines between the CPE and the switch by placing test calls to a 108-type test line. Operations available through BRI access to the 108-type test line include the following: o Provide TSI loopback terminations o Send a pseudo-random bit pattern o Receive and measure a pseudo-random bit pattern o Perform continuity test of BRI path o Verify signaling operation of the D-channel. Additional information on feature, BRI access to the 108-type test line, and procedures for its use are included in AT&T 235- 105-220, Corrective Maintenance Procedures. The automatic test for lines is the automatic line insulation test (ALIT). An ALIT uses the line insulation circuit in the modular metallic service unit (MMSU) and the metallic connections provided by the MMSU to the lines in the line unit to detect gradual cable deterioration. An ALIT may be inhibited on a line-by-line basis using the RC/V subsystem. The number of ALIT circuits should be engineered to make it possible to test all of the lines in the office in about 8 hours. For maximum efficiency of the testing session, all of the available ALIT circuits are used in parallel. There are four types of ALIT tests. These tests are as follows: o Foreign electromotive force (FEMF) o Short circuit and ring to ground (SRG) o Tip and ring to ground (TRG) o All of the previous. Maintenance personnel are allowed to enter administrative functions using input messages. Emergency situations may make it necessary for a line to be removed from service and placed in one of several specific out-of-service (OOS) states. If the line is busy, it is camped-on and waits for control. The message seized is displayed in the test area when the line is free for testing. When the line is camped-on, the maintenance personnel cannot perform any test requests. Only the busy- monitor or monitor busy and idle commands can be used during the camped-on period if the maintenance personnel wants to ``listen in.'' If the maintenance personnel does not want to wait for the line to become available, a release command can be performed at this time. An alternative to entering a release command is to enter new line data at the same test position. When new data is entered, the old test in progress is automatically torn down. In the test area, the message ONLY MNTR BUSY (5E6) or DO MNTR BUSY [4600] OR B&I [4601] ONLY (5E7 and later) is displayed. All other test requests cause an error message. If the control of the line is not obtained within 5 minutes, a message in the test area, RL - FAILED TO OBTAIN BUSY PORT is displayed. When the line becomes available for testing, the graphic representation is changed from CAMPED ON to SEIZED. Only one test position at a time is able to access a specific line. In other words, two test positions cannot access the same line. Camping on to a line that is being tested at another test position is not allowed. A message is displayed in the test area stating that the line just entered is already being tested. The following administrative functions are provided by the TLWS: o Removing line from service o Restoring line to service o Unconditionally restoring failed line to service o Line status is displayed when line is seized o Line identification [line equipment number (LEN) or directory number (DN)] is displayed when line is seized. There are several functions of the TLWS that deal with both trunks and lines. Some of these functions are as follows: o Talk and monitor o Retiring alarms o Routing messages o Scheduling tests o Outputting general information o Outputting machine detected interoffice irregularity (MDII) reports o Restoring trunks. Note: All of the previous functions can be performed from the STLWS terminal. The talk and monitor phone is used to connect to a trunk or line in order to test the circuit. No test equipment is used between the talk and monitor phone and the circuit under test when it is used from the TLWS. This operation would normally be done to call the maintenance personnel in another office or to monitor a trunk or line. The talk and monitor phone is the terminating end of the 101 test line call. When the far-end craft and/or maintenance person dials the 101 test line directory number, the call terminates at the talk and monitor phone. If the near-end person requests transmission testing on the 101 test line call, the connection is put in the monitor mode for monitoring interactive test. Note: Talk and monitor is not supported for wideband calls. To verify the operation of the ISTF loopback feature, the craft can place an interoffice call to the 108-type test line which has the inverting option (LBKINV). If the loopback feature is operational, the squelch of the data stream should be clearly audible. Alarms can be turned off at the STLWS by depressing the alarm release (ALM RLS) function key. Status display alarm indications remain until the alarm condition is repaired. Output messages can be routed to the TLWS or to the remote switching control center, depending on whether the TLWS office is staffed. A routine test scheduler is provided for APT and ALIT. Maintenance personnel can override the routine test scheduler by entering new parameters for the test session. The new parameters are for the next session only. The automatic scheduler then returns to the preprogrammed schedules for test sessions. Many types of information can be requested and received at the TLWS. The information can then be printed at the ROP. Some requests are as follows: o List of carrier group alarm (CGA) trunks o CGA member number o Member number of active CGAs o Number of active CGAs o Perform conversion of equipment identifiers o Convert member number to equipment number o Conversions between DNs and LENs. Due to emergencies or intensive test sessions, MDII reports may need to be stopped temporarily. Therefore, the maintenance personnel can control the MDII reports by entering the input message INH:MDII (see AT&T 235-600-700, Input Messages Manual, for details). When the user desires to have the MDII reports printed again, enter the input message ALW:MDII (see AT&T 235-600-700 for details). If the user desires to change the device(s) that receive the MDII reports, the ECD (classdef) must be changed to reflect the desired device. Refer to AT&T 235-600-30X, ECD Data Base Manual, where X = the manual number associated to the applicable software release. See AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of the ECD data base manuals. When a trunk or group of trunks is restored conditionally by the maintenance personnel, the default test call is run. The default trunk test information (for example, the test type and trunk group number) is stored in the Automatic Trunk Test Table. If the test fails, the trunk or trunk group may or may not remain OOS. The trunk remains OOS if the OOS trunk group threshold has been exceeded. The miscellaneous test commands associated with the TLWS menu can be grouped by function and are used to perform operations on specific lines or trunks. The commands must be entered from task selection Page 9000 (5E8 and earlier) or Pages 9000,1 and 9000,2 [5E9(1) and later]. (Refer to Table .AW TJ/ for examples of Pages 9000, 9000,1 and 9000,2 and to Section .RM 3.9.3/ for descriptions of commands appearing on each page. The test access unit (TAU) is of specific interest to the TLWS user. The TAU provides several plug-in jacks. These jacks are used in conjunction with portable test equipment and system software control to gain trunk or line access and perform tests. The following jacks are provided: o TEL A and TEL B - to the interframe communications circuit (TEL=telephone) o TEL A MON and TEL B MON - to the interframe communications circuit (TEL=telephone) o DIRECT ACCESS 1 and DIRECT ACCESS 2 - for direct connection o ANALOG ACCESS 1 and ANALOG ACCESS 2 - each with S, R, and ear & mouth (E&M) jacks for analog connection (S=send, R=receive) o Four spare jacks for future applications. The directly connected test unit (DCTU) is a test set that is integrated into the 5ESS switch to provide basic metallic tests. These tests can be performed by the DCTU without using the portable test equipment. Any analog line, universal digital subscriber line (UDSL), or 2-wire trunk that terminates metallically to the switch can be tested. Control of the DCTU is via commands entered at the TLWS which identifies the particular line or trunk under test from previous seize line or trunk requests. Measurements requested at the TLWS are taken by the DCTU and transmitted back to the TLWS for display on the terminal. The Remote Office Test Line (ROTL) feature allows interoffice trunk testing automatically from a Centralized Automatic Reporting on Trunks (CAROT) system. The CAROT system is a computerized system that accesses and tests trunks for a maximum of 14 offices simultaneously. The 5ESS switch ROTL supports the following capabilities: o Transmission tests - 100, 102, and 105 test lines o Connection appraisal - 100, 102, and 105 test lines o Security callback o Trunk make-busy and restore o Trunk status request o Balance and long-term test. The 100, 102, and 105 test lines are at the far end of the trunk. Transmission test calls and connection appraisal calls are placed via ROTL toward the distant test lines. The ROTL supports test calls toward the indicated test lines by providing trunk access and seizure, and outpulsing of the digits necessary to reach the test line. Also, a tone detection capability is provided that recognizes when the indicated test line has answered the test call. The transmission tests listed previously can also be performed locally by using the TST:TRK input message. The ROTL functions consist of answering calls from the CAROT controller, receiving information in the form of multifrequency (MF) digits, and causing trunks to be accessed and attached to the responder for transmission measurements. Note: ROTL initiated trunk testing is denied on trunks assigned to a 5ESS switch for AUTOPLEX System 1000 traffic. Refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures, for details concerning the hardware functions, trunk conditioning, test performed by ROTL, and the ODD requirements. Table .AW TJ/ lists each TLWS task selection, the TLWS page number, the applicable 5E6 and later software release, and the figure number that show an example of each page. This section contains the TLWS task selection pages for 5E6 and later software releases. All commands shown on these task selection pages are listed and described in Section .RM 3.9.3/. See Figures .AW G18/, .AW G19/, and .AW G20/. See Figures .AW G21/, .AW G22/, and .AW G23/. See Figures .AW G24/ and .AW G25/. See Figures .AW G26/ and .AW G27/. See Figure .AW G28/. See Figures .AW G29/, .AW G30/, and .AW G31/. See Figures .AW G32/ and .AW G33/. See Figure .AW G34/. See Figures .AW G35/ and .AW G36/. See Figures .AW G37/, .AW G38/, and .AW G39/. See Figures .AW G40/ and .AW G41/. See Figures .AW G42/, .AW G43/, and .AW G44/. See Figures .AW G45/ and .AW G46/. See Figures .AW G47/, .AW G48/, and .AW G49/. See Figures .AW G50/, .AW G51/, and .AW G52/. See Figures .AW G53/, .AW G54/, and .AW G55/. See Figures .AW G56/ and .AW G57/. See Figures .AW G58/ and .AW G59/. See Figures .AW G60/ and .AW G61/. See Figures .AW G62/ and .AW G63/. See Figures .AW G64/ and .AW G65/. See Figures .AW G66/ and .AW G67/. See Figures .AW G68/, .AW G69/, and .AW G70/. See Figure .AW G71/. See Figures .AW G72/ and .AW G73/. See Figure .AW G74/. See Figure .AW G75/. See Figures .AW G76/, .AW G77/, and .AW G78/. See Figure .AW G79/. This section contains a listing and brief description of each 5E6 and later TLWS command. Commands are listed in numerical order. 2 CMD RESULT 2000 The seized line or trunk is removed; state changed to OOS. TST:WSAUTO,TP=Z,RMV 21XX The CPEXX is removed from service. [For 5E6 - 5E8, only valid for CPEs which support testing. For 5E9(1) and later, valid for standard BRI CPEs and custom multipoint CPEs which support testing.] TST:WSCPE,TP=Z,TEST=RMV,CPE=XX 3000 The seized line or trunk is diagnosed, restored if diagnostic passes, and is released from TLWS control; state changed to IS. TST:WSAUTO,TP=Z,RST 31XX The CPEXX is restored to service. [For 5E6 - 5E8, only valid for CPEs which support testing. For 5E9(1) and later, valid for standard BRI CPEs and custom multipoint CPEs which support testing.] TST:WSCPE,TP=Z,TEST=RST,CPE=XX 4001,X DN X is seized. CONN:WSLINE,TP=Z,DN=X 4002,X LEN X is seized. CONN:WSLINE,TP=Z,LEN=AA,BB,CC,DD,EE,FF 4003,X SLEN X is seized. CONN:WSLINE,TP=Z,SLEN=AA,GG,HH,II 4004,X MLHG X is seized. CONN:WSLINE,TP=Z,MLHG=JJ,KK 4005,X LCEN X is seized. CONN:WSLINE,TP=Z,LCEN=AA,LL,MM,NN 4006,X AP X is seized. CONN:WSLINE,TP=Z,AP=OO,PP 4007,X DN member X is seized. CONN:WSLINE,TP=Z,DN=QQ,KK 4008,X ILEN X is seized. CONN:WSLINE,TP=Z,ILEN=AA,RR,SS,TT or CONN:WSTRK,TP=Z,ILEN=CC,LL,MM,NN 4101,X TG X is seized. CONN:WSTRK,TP=Z,TG=X 4102,X TKGMN X is seized. CONN:WSTRK,TP=Z,TKGMN=AA,BB 4103,X TEN X is seized. CONN:WSTRK,TP=Z,TEN=CC,DD,EE,FF,GG 4104,X DEN X is seized. CONN:WSTRK,TP=Z,DEN=CC,HH,II,JJ 4105 The next member of TG is seized. CONN:WSTRK,TP=Z,NEXTMEM CMD RESULT 4106,X RAF X is seized. CONN:WSTRK,TP=Z,RAF=CC,KK,BB Note: Variables for commands 4002,X, 4003,X, 4004,X, 4005,X, 4006,X, 4007,X, 4008,X, 4102,X, 4103,X, 4104,X, and 4106,X are defined at the end of this listing. 4200 Incoming 101TL call is seized. CONN:WSIC,TP=Z 4300 Talk and monitor (T&M) phone is disconnected. DISC:WSPHONE,TP=Z 4301 T&M phone is connected. CONN:WSPHONE,TP=Z 4302 The mode of the T&M phone connected to the indicated test position (TP) is set to talk so the user can talk and listen. SET:WSPHONE,TP=Z,MODE=TALK 4303 The mode of the T&M phone connected to the indicated TP is set to monitor so the user can only listen. SET:WSPHONE,TP=Z,MODE=MNTR 4304 The mode of the T&M phone connected to the indicated TP is set to on hold. SET:WSPHONE,TP=Z,MODE=TEST 4305,X The digits X are used for outpulsing to the remote T&M phone. SET:WSPHONE,TP=Z,MODE=OVER,DN=X 4400 The digits for outpulsing are cleared. CLR:WSOPD,TP=Z 4401,X The digits X are set to be used for outpulsing and/or are outpulsed over the seized trunk. SET:WSOPD,TP=Z,OPD=X 4500 The frequency and level at a particular TLWS TP are cleared. CLR:WSFREQ,TP=Z 4501,X,Y The frequency is set to X and/or the level is set to -Y to be used later with TST:WSSEND. SET:WSFREQ,TP=Z,FREQ=X,LVN=Y 4502,X,Y The frequency is set to X and/or the level is set to +Y to be used later with TST:WSSEND. SET:WSFREQ,TP=Z,FREQ=X,LVP=Y 4503,V,W,X,Y User defined default values are set; termination is set to V, block size is set to W, channel is set to X, and test equipment is set to Y. Values are to be used later with TST:WSDGTL,USERDEF (DSL). SET:WSDGTL,TP=Z,TERM=V,BLKSZ=W,CHAN=X,TESTEQ=Y 4504,V,W User defined default values are set; termination is set to V and block size is set to W. Values are to be used later with TST:WSDGTL,USERDEF (TRUNK). SET:WSDGTL,TP=Z,TERM=V,BLKSZ=W,TRUNK CMD RESULT 4505 The values for TERM, BLKSZ, CHAN, and TESTEQ are cleared. CLR:WSDGTL,TP=Z 4600 The audio of a busy line or trunk is monitored from the T&M phone. TST:WSMNTR,TP=Z,MODE=BUSY 4601 The audio of a busy or idle line or trunk is monitored from the T&M phone. TST:WSMNTR,TP=Z,MODE=IDLE 4800 The line or trunk most recently requested for seizure on the TP is reseized. CONN:WSLINE,TP=Z or CONN:WSTRK,TP=Z or CONN:WSPORT,TP=Z (5E8 and later) 4999 The seized line or trunk is released. DISC:WSLINE,TP=Z or DISC:WSTRK,TP=Z or DISC:WSPORT,TP=Z (5E8 and later) 5001 Tone is sent over seized line or trunk. TST:WSSEND,TP=Z,TEST=SEND 5002,X,Y Tone at frequency X is sent at level -Y over seized line or trunk. TST:WSSEND,TP=Z,SEND,FREQ=X,LVN=Y 5003,X,Y Tone at frequency X is sent at level +Y over seized line or trunk. TST:WSSEND,TP=Z,SEND,FREQ=X,LVP=Y 5004 Tone of 404 Hz is sent at level 0 over seized line or trunk. TST:WSSEND,TP=Z,SEND,FREQ=404,LVP=0 5005 Tone of 1004 Hz is sent at level 0 over seized line or trunk. TST:WSSEND,TP=Z,SEND,FREQ=1004,LVP=0 5006 Tone of 2804 Hz is sent at level 0 over seized line or trunk. TST:WSSEND,TP=Z,SEND,FREQ=2804,LVP=0 5007 The open termination test is sent over seized trunk. TST:WSSEND,TP=Z,TEST=OPEN 5008 The quiet termination test is sent over seized trunk. TST:WSSEND,TP=Z,TEST=QUIET 5031 Digital loopback test is run on seized line or trunk using default values. TST:WSDGTL,TP=Z 5032,X,Y,Z (5E8 and earlier) Digital loopback test is run on seized line using termination X, block size Y, and channel Z. TST:WSDGTL,TP=P,TERM=X,BLKSZ=Y,CHAN=Z 5032,W,X,Y (5E9(1) and later) Digital loopback test is run on seized line using termination W, block size X, and channel Y. TST:WSDGTL,TP=P,TERM=W,BLKSZ=X,CHAN=Y 5033,X,Y Digital loopback test is run on seized trunk using termination X and block size Y. TST:WSDGTL,TP=Z,TERM=X,BLKSZ=Y CMD RESULT 5034 Digital loopback test is run on seized line or trunk using default values defined and preset by the user. TST:WSDGTL,TP=Z,USERDEF 5035,Z Test equipment ID of selected channel is displayed. TST:WSDGTL,TP=Y,TESTEQ=Z 5100 The composite measurement is done on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=MEASURE 5101 The broadband level is measured on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=BBAND 5102 The far-to-near noise level is measured on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=NOISE 5103 The far-to-near level at 1004 Hz -16 dB is measured on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=NWT 5104 The echo-return loss is measured on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=ERL 5105 The singing-return loss is measured on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=SRL 5106 The singing-return loss, high, is measured on the seized line or trunk. TST:WSMEAS,TP=Z,TEST=SRLHI 5201 The receiver off-hook test is run on the seized line. TST:WSSUPV,TP=Z,TEST=ROH 5202 The ring test is run on the seized line. TST:WSSUPV,TP=Z,TEST=RING 5203 The trunk on-hook test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=ON 5204 The trunk off-hook test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=OFF 5205 The wink test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=WINK 5206 The quick wink test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=QWINK 5207,X The digital service unit 2 - recorded announcement function (DSU2-RAF) phrase X is played. TST:WSSUPV,TP=Z,TEST=PHRASE,PHRASE=X 5208,W,X,Y,Z The DSU2-RAF announcement is played with application W, header announcement X, tail announcement Y, and inflection Z. TST:WSSUPV,TP=P, TEST=ANN,APPL=W,HANN=X,TANN=Y,INFL=Z 5209 The defense switch network preemption tone test is run on the seized line. TST:WSSUPV,TP=Z,TEST=PPTONE 5210,W,X,Y,Z The DSU2-RAF dial-through announcement test is run with application W, header announcement X, tail announcement Y, and inflection Z. TST:WSSUPV,TP=P, TEST=DTA,APPL=W,HANN=X,TANN=Y,INFL=Z CMD RESULT 5212 The network termination 1 mismatch test is run on the seized line. TST:WSSUPV,TP=Z,TEST=MSMTCH 5221 The ringback test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=RNGBK 5222 The operator attached signal test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=OPAT 5223 The operator released signal test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=OPRL 5224 The coin collect signal test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=CNCL 5225 The coin return signal test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=CNRT 5226 The coin collect and operator released signal test is run on the seized trunk. TST:WSSUPV,TP=Z,TEST=CCOR 53XX,Y,Z An interactive digital test with a loopback established at CPEXX is performed using block size Y on channel Z (only valid for CPEs that support testing). TST:WSCPE,TP=P,TEST=LPBK,CPE=XX,BLKSZ=Y,CHAN=Z 5401 The line insulation test (LIT) is performed on the seized line. TST:WSAUTO,TP=Z,LIT 5402 The automatic digital subscriber line (DSL) test is run on the seized line using default values. TST:WSAUTO,TP=Z,TSTDSL 5403,V,W,X,Y,Z The automatic DSL test is run on the seized line using termination V, duration W, block size X, channel Y, and acceptable bit error rate Z. TST:WSAUTO,TP=P,TSTDSL,TERM=V,DUR=W,BLKSZ=X, CHAN=Y,ABER=Z 5404 The automatic line evaluation (ALE) session is run on the seized line, and error counts are reported. TST:WSAUTO,TP=Z,ALE=ALL,REPT 5405 The automatic trunk test is run on the seized trunk using default values. TST:WSAUTO,TP=Z,TSTTRK 5406,X The automatic trunk test of type X is run on the seized trunk. TST:WSAUTO,TP=Z,TSTTRK,TYPE=X 5407,X,Y The automatic trunk test of type X using outpulse digits Y is run on the seized trunk. TST:WSAUTO,TP=Z,TSTTRK,TYPE=X,OPD=Y 5408 The seized line or trunk is diagnosed. TST:WSAUTO,TP=Z,DGN 5409,W,X,Y,Z The automatic trunk test is run on the seized trunk using type W, outpulse digits X, duration Y, and block size Z. TST:WSAUTO,TP=P,TSTTRK,TYPE=W,OPD=X,DUR=Y,BLKSZ=Z 5410 The automatic DSL fault sectionalization test is run on the seized line using default values. TST:WSAUTO,TP=Z,TSTDSL,SECT CMD RESULT 5411,T,W,X,Y,Z The automatic DSL fault sectionalization test is run on the seized line using termination T, duration W, block size X, channel Y, and acceptable bit error rate Z. TST:WSAUTO,TP=P, TSTDSL,SECT,TERM=T,DUR=W,BLKSZ=X,CHAN=Y,ABER=Z 5411,S,T,W,X,Y,Z The automatic DSL fault sectionalization test is run on the seized line using termination S, duration T, block size W, channel X, mode Y, and acceptable bit error rate Z. TST:WSAUTO,TP=P, TSTDSL,SECT,TERM=S,DUR=T,BLKSZ=W,CHAN=X, MODE=Y,ABER=Z 5412,X,Y The ALE session is run on type X using option Y. TST:WSAUTO,TP=Z,ALE=X,Y 5413,X The automatic DSL cyclic redundancy check (CRC) test is run on the seized line for duration X. TST:WSAUTO,TP=Z,TSTDSL,TEST=CRC,DUR=X 5413,X,Y The automatic DSL CRC test type X is run on the seized line for duration Y. TST:WSAUTO,TP=Z,TSTDSL,TEST=X,DUR=Y 5414 The network termination 1 mismatch test is run on the seized line. TST:WSAUTO,TP=Z,TSTDSL,TEST=MSMTCH 5415 An in-progress call trace is requested on the port known to the TLWS (SEIZED, CAMPED, or UNDER TEST). TST:WSAUTO,TP=Z,IPCT 5601 The voltage, resistance, and capacitance tests are performed on the seized line or trunk. TST:WSMET,TP=Z,TEST=ALL 5602 The voltage test is performed on the seized line or trunk. TST:WSMET,TP=Z,TEST=V 5603 The resistance test is performed on the seized line or trunk. TST:WSMET,TP=Z,TEST=R 5604 The capacitance test is performed on the seized line or trunk. TST:WSMET,TP=Z,TEST=C 5605 The distance-to-open test is performed on the seized line. TST:WSMET,TP=Z,TEST=DIST 5606 The ringer count test is performed on the seized line. TST:WSMET,TP=Z,TEST=RINGER 5607 The home totalizer test is performed on the seized line. TST:WSMET,TP=Z,TEST=HT 5608 The detect coin test is performed on the seized line. TST:WSMET,TP=Z,TEST=DC 5609 The collect coin test is performed on the seized line. TST:WSMET,TP=Z,TEST=CC 5610 The return coin test is performed on the seized line. TST:WSMET,TP=Z,TEST=RC 5611 The monitor-for-short test is performed on the seized line. TST:WSMET,TP=Z,TEST=SHORT CMD RESULT 5612 The pair gain test controller (PGTC) is added into the metallic connection on the seized port. TST:WSMET,TP=Z,TEST=PGTC 5801 The seized line or trunk is connected to the test access unit (TAU) jack AC1 for digital testing. CONN:WSJACK,TP=Z,JACK=AC1 5802 The seized line or trunk is connected to TAU jack AC2 for digital testing. CONN:WSJACK,TP=Z,JACK=AC2 5803 The seized line or trunk is connected to TAU jack DC1 for metallic testing. CONN:WSJACK,TP=Z,JACK=DC1 5804 The seized line or trunk is connected to TAU jack DC2 for metallic testing. CONN:WSJACK,TP=Z,JACK=DC2 5990 The test is stopped, and all associated testing hardware is released. RLS:WSTST,TP=Z 5999 Any test that is running on the seized line or trunk is stopped. STP:WSTST,TP=Z 9200 The CPE information for the line seized is displayed on the TLWS screen. TST:WSCPE,TP=Z,TEST=CPE 9201 The USPID information for the line seized is displayed on the TLWS screen. TST:WSCPE,TP=Z,TEST=USPID 9500 The test results from the specified TLWS test position are printed immediately or with [,LOG] option set for automatic printing. OP:WSDATA,TP=Z 9600 The testing status of TLWS test position Z is printed. OP:WSSTAT,TP=Z 9601 The testing status of all TLWS test positions is printed. OP:WSSTAT 9602 All default values defined and preset by the user are displayed. OP:WSDATA,TP=Z,USERDEF 9700 The CPE information along with information about CPE provisioned for service on the DSL is printed. TST:WSCPE,TP=Z,TEST=PRINT The variables for commands 4002,X, 4003,X, 4004,X, 4005,X, 4006,X, 4007,X, and 4008,X (Line) are as follows: AA=SM KK=MEM BB=LU LL=ISLU CC=GR MM=LNGRP DD=BD NN=LCN EE=SW OO=AP FF=LV PP=RL GG=DCLU QQ=DN HH=RT RR=IDCU II=Line SS=RT or DS1 JJ=GRP TT=LT or DS0 The variables for Commands 4008,X (Trunk), 4102,X, 4103,X, 4104,X, and 4106,X are as follows: AA=GRP HH=DLTU BB=MEM II=DFI CC=SM JJ=CH DD=TU KK=RAF EE=SG LL=IDCU FF=BD MM=RT or DS1 GG=CKT NN=LT or DS0 The recent change/verify (RC/V) system is a function that allows maintenance personnel access to the 5ESS switch data base. The RC/V system is used to: add to, delete from, update, or verify the data base. A stand-alone RC/V subsystem is provided at the 5ESS switch. Therefore, operation support system (OSS) interfaces are not required to use RC/V capabilities. The stand-alone RC/V enables craft and/or maintenance personnel to change or verify the data base using video displays and menu selection. For detailed information applicable to recent change/verify procedures [AT&T 235-118-XXX (XXX = manual number associated to applicable software release)], refer to AT&T 235- 000-000, Numerical Index - Division 235 and Associated Documents. The screen program allows the craft to run office data base editor (ODBE), access editor (ACCED), and UNIX(R) operating system shell via the SCC data link or at the MCC terminal. For offices that have 5E7 and later software releases, the screen program allows the craft to run the Common Network Interface Data Base Consolidator (CNIDBOC). For offices that have 5E9(1) and later software releases, the screen program allows the craft to run the Automated Circuit Pack Return Tag (RTAG) tool. Also, the screen program provides page-at-a-time output filtering for ODBE, ACCED, UNIX operating system shell, CNIDBOC, and RTAG from other terminals in the office. At the SCC, MCC, or STLWS terminal, enter poke command 194 to activate the screen program. Also, the screen program can be activated via the input message RCV:MENU:SCREEN. Note: If the user enters the RCV:MENU:SCREEN from a terminal that accepts poke commands, a rejection message appears indicating that the poke command 194 should be used instead of the RCV:MENU:SCREEN message. Main Menu Display Page After the user enters the poke command/input message successfully, the main menu page is displayed (see Figures .AW G80/, .AW G81/, and .AW G82/). Select the desired program, by entering the appropriate command [where o = ODBE, a = ACCED, u = UNIX program, c = CNIDBOC (for 5E7 and later) or r = RTAG (for 5E9(1) and later]. To exit the screen program, enter Q. Once a desired program has been selected, the user can begin entering commands on the terminal. Running programs from the screen program is similar to running programs directly from the UNIX program. However, some differences do exist and are explained in the following sections. Entering Special Characters Certain characters cannot be directly entered from all types of terminals in the office. The following identifies characters that need a 2-character representation. ********************************************************************** DESIRED ENTER TWO CHARACTER CHARACTER REPRESENTATION --------- ----------------------- ; \\: _ \\- ! \\1 $ \\s & \\8 @ \\a ? \\/ \\ \\\\ ********************************************************************** Paging and Scrolling The screen program displays the user's entries and the responses on the terminal starting from the top of the screen and working towards the bottom. When the user has filled the screen, the screen program scrolls (that is, rewriting the affected lines) the display upward. Scrolling automatically stops so the user can review any line that was not visible since the last user input command. When scrolling stops for this reason, the message shown in Figure .AW G83/ is displayed: At this point, the user can enter NP, RUN, or wait for the 2- minute timeout. If NP is entered or the 2-minute timeout occurs, the screen continues to scroll again until either the display fills with new lines (the *MORE* prompt is displayed) or until the output is complete (whichever occurs first). If RUN is entered, the screen continues to scroll again until the output is complete. Clear Screen If the user desires to clear the display screen and have the output to fill in the screen from the top, enter CS. Note: The CS cannot be used when user is in the main menu mode or when output is paused with the *MORE* prompt. Break Program in Progress The user can send a break signal to stop the program running (via the screen program) by entering BREAK. Note: The BREAK cannot be used when user is in the main menu mode or when output is paused with the *MORE* prompt. Exiting Screen Program Note: The user cannot exit the screen program when in the main menu mode or when the output is being paused with the *MORE* prompt. The user can exit the screen program by doing the following: 1. Entering Q or EOF to return to main menu 2. Entering Q to exit the screen program. Abort Screen Program The user can abort the program being run by the screen program as follows: a. If the *MORE* prompt displayed, enter RUN. b. If the program is ``not'' at the *MORE* prompt or if RUN has been entered, enter either Q or EOF. Depending on the state of the program aborted, in about 2 minutes the screen program will either return the user to the main menu or exit entirely. When using the screen program, do not attempt to direct any output to the terminal by redirecting to the UNIX program port name. If user needs to direct output to the terminal, use the ``1pr'' UNIX program command as follows: date | 1pr ttyv # When using the UNIX operating system shell from within the screen program, do not run interactive programs (that is, Ibrowse, apprc, genbkup, ODBE, rcvecd, rcvsg, ACCED, CNIDBOC, or RTAG). These interactive programs are not compatible with the screen program when running directly from the UNIX operating system shell. However, we know that ODBE, ACCED, CNIDBOC, and RTAG can be run from the screen program's main menu. Note: The ``ed'' editor can be used with the screen program. If the user accessed the screen program via poke command 194, other display pages cannot be accessed until the user exits the screen program. The following message can appear when exiting the screen program: UNRECOVERABLE FAULT This response indicates some event (such as the TTY channel detecting errors) that the screen program was unable to compensate for, occurred. The input message area is used to enter human-interface input messages. These messages are comprised of alphanumeric abbreviations instructing the system to perform required tasks. DGN:MCTSI=1-1,RPT=5,TLP; is a sample message. It instructs the switch to diagnose the module controller unit 1 in interface module 1, repeat the diagnostic five times, and provide a trouble location process (TLP) printout. The basic method for inputting a message is to enter it on the bottom line of the input message area and execute it with the semicolon (;). An acknowledgment is returned by the system within seconds from the time the semicolon was entered. At the time the acknowledgment is issued, the message with acknowledgment is scrolled up one line to clear the bottom line for the entry of an input message. It is also printed on the ROP. The cursor is then automatically repositioned at the start of the bottom line for entry of the next input message. The message display page may be used to display the message(s) in the control and display portion of the video display terminal. When the message display page is not displayed, the message with acknowledgment continues to be displayed on the next to the bottom line until another message is executed or the next output message is printed. When the display message page is used, the message with acknowledgment is printed on the ROP and scrolled into the control and display area. Message input formats may be selected by using different end- of-line characters for input messages. The placement of the cursor on the input line is dependent upon what message input format has been selected. Different input formats are possible by using various end-of-line characters. They are as follows: a. ; (MML) executes (and terminates) all types of input formats. b. ! (MML) continues message that is more than one line long. Multiple line input messages may be entered by using the forward exclamation point (!) at the end of each command line. The message can be terminated after the last line with the semicolon (;). This format causes the input subsystem to save all the information entered by each message line and then act on the saved data after the final message line is entered. Once an input message line has been entered, the procedure for entering another line is the same as the one for messages using the exclamation point. When the last message line is entered, the message lines are placed sequentially into the output stream and printed. The capability to erase or cancel characters just entered (versus characters repeated) is provided. Input the underscore (_) character or backspace for each character back to and including the character to be erased or canceled. The entering of the underscore or backspace once a message has been executed (end-of-line character entered) is prohibited. The input message entry area is cleared and any incomplete input format in progress canceled by entering <del> key on the input line. A single-input line can be restarted (cleared of input entered) at any time by entering the @ character. The input cleared by these functions will not be printed on the ROP. The RETURN and ENTER keys will be accepted in place of the exclamation (!) or semicolon (;) and echo the characters when used. Table .AW TK/ explains line administration and end-of-line characters. Effective with the 5E9(1) software release, input message editing and history are provided by the system. A history mechanism maintains a list of up to 200 input commands that have been previously entered and saved on a given terminal. These saved commands can be recalled, edited, and then reexecuted. Commands saved in the list can be recalled by number or with a search string. The last command also can be recalled directly. Once a command is recalled, the user can append or substitute until the desired new command is constructed. The new command can then be executed. The User Guidelines section in AT&T 235-600-700, 5ESS Switch Input Messages Manual, Volume 1, contains detailed information on input message editing and history. When a valid command is executed, it is sent to the subsystem that performs the function. If a command does not meet the following criteria, the NG acknowledgment is displayed. o Is not from the page currently displayed o Is not a valid page selection command o Cannot be executed with the current system configuration. If the subsystem is unable to perform the function because of a lack of system resources, the RL acknowledgment is displayed. When a subsystem accepts the requested command and is able to start the function, a PF acknowledgment is displayed to indicate that the completion results of the function are forthcoming on the printer. At the time the PF is displayed, a message identifying the action requested and its origin is printed on the printer. The NG, RL, and PF are displayed within seconds from the time of execution of the command. The command with acknowledgment is displayed on line 4, column 25. When the MSG (message) input mode is selected, the MCC is placed in a state for entering a human-interface input message. While in this mode, the system performs timing checks for the interval between characters. This interval is 45 seconds. If an expected character is not input within this interval, a ?T acknowledgment is issued, the line is scrolled up one, and the cursor is repositioned at the start of the input message entry line. Several additional acknowledgments are used to signify syntax, unit selection, and execution errors as defined in AT&T 235- 600-700, Input Messages Manual, Volume 1, User Guidelines section. Two possible conditions that prevent an input mode (CMD or MSG) from being selected are a duplex-processor failure or a failure of the interface between the AT&T 3B20 computer and the video display terminal. A help feature is provided on input messages that provides the following: o Improved error messages in cases where syntax or semantic errors are found on entered messages. o Help on input messages formats, including argument type and range. o Prompting for entering input messages. For more information on how to get help, how to get prompted for keywords or parameters, and how to terminate help, refer to AT&T 235-600-700, Input Messages Manual, Volume 1, User Guidelines section. Any deviation from normal system operating conditions produces a printout on the MCC or remote switching control center. The printout contains all data relevant to the condition, diagnostic results, and a list (by priority) of suspected faulty circuit boards. Periodic traffic and plant summaries are also printed on the ROP. All of these printouts are important in determining system status, with diagnostic information and circuit board lists being of primary importance to maintenance personnel. The printer should be connected whenever maintenance is being performed in the office. For detailed analysis of printouts, refer to AT&T 235-600-750, Output Messages Manual. This section describes the ODBE at a high level. For a more detailed description or before using ODBE, refer to AT&T 235- 105-220, Corrective Maintenance Procedures. The ODBE is a tool which allows maintenance personnel to make manual changes to the 5ESS switch data base. Information is stored in the data base in relations which are groups of predefined, associated attributes. Each instance of data in a relation is referred to as a tuple. Relations, tuples, and attributes can be viewed as a table (the table being a relation) where each item (row) in the table is a tuple, and each column in the table is an attribute. The ODBE manipulates this relational data base structure. Refer to AT&T 235-600-10X (X = manual number associated to applicable software release), Translations Data Manuals, for details concerning the attribute and relation names, attribute and relation descriptions, population rules for each attribute, and other applicable information. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of AT&T 235-600-10X, Translations Data Manuals. Caution: By using ODBE, it is possible to update, delete, or insert information into ODD relations which is critical to the operation of the 5ESS switch. Improper use of ODBE can be service affecting. Before updating, deleting, or inserting information into a base relation, consult local supervision concerning policy. The ODBE offers a user the ability to create, inspect, and modify the contents of the data base in an interactive mode. It is driven by data definition information which is contained in the 5ESS switch data dictionaries and accessed through the data base manager (DBM) interface. This interface permits the user to review, update, insert, and delete information in the data base one tuple at a time. Any relation defined in the data dictionaries can be inspected and modified. The ODBE is controlled by input from the RC/V, TLWS, STLWS, or the MCC (Page 194) video display terminals. The output data is displayed at the terminal where input is entered and cannot be displayed on the ROP. The input message, RCV:MENU:[DATA,]ODBE;, is used to access the ODBE function on the terminal. Note: The keyword DATA in the input message is optional. If the switch accepts the input message, the system responds with a printout follows (PF) followed by an output message, OFFICE DATA BASE EDITOR. A password may optionally be required to use ODBE. When using ODBE, the response of the user to a given prompt is usually a data base defined name, an encoded choice from a menu of options, or an ODBE special character. The ODBE is a finite state process and, as such, has a set of states, inputs, and resulting states. Following are the possible ODBE states: 1. Enter processor number (the highest state) 2. Enter relation name 3. Enter tuple operation 4. Enter primary key 5. Enter attribute value (the lowest state). Special characters have a meaning only if they are the first character in a user response. All special characters and their meanings can be found in AT&T 235-105-220, Corrective Maintenance Procedures. The most commonly used special characters include an exclamation (!), which lifts the user to the next higher state (for example, ``Enter Primary Key'' to ``Enter Tuple Operation''), control-d, which exits ODBE (that is, depressing CTRL and d keys simultaneously will end the ODBE session), and a question (?) which will display valid possible responses for that state. When possible user values are listed in the following sections, special character entries will not generally be listed. When data is input into ODBE, white space (blanks, tabs, new lines, etc.,) is ignored and only delimits item values. White space may be input as an item value by placing the entire value in double quote characters (" "). This holds true whether the input is interactive or from a bulk input file. In the Enter Processor Number state of ODBE, the user is prompted for the processor/module number where the data in question resides. Following is a list of possible responses to the prompt: o 1-192 for the SM number o 193 for the AM (5E6 and later software releases) o 194-205 for the primary CMP number (5E6 and later software releases) o 206-217 for the mate CMP number (5E6 and later software releases) o ALL for redundant tuple read. Note: The ``ALL'' response refers to an ODBE feature that allows the user to examine redundant or partitioned tuples across all SM processors. Upon selecting the ``ALL'' option, the user is prompted for the relation name and then a key value. All tuples that match this key across all SMs is written to a user-specified file. This feature is useful for debugging split translations when one SM has inconsistent data in association to other SMs. In the Enter Relation Name state of ODBE, the user is prompted for the base relation name. See AT&T 235-105-220, Corrective Maintenance Procedures, for additional details concerning these responses. Following is a list of possible responses to the prompt: 1. Valid relation name. (When a relation name is entered, ODBE goes into the Enter Tuple Operation state.) 2. PARAMETER to edit parameters. Parameters are global variables which are used for ODD sizing, ODD engineering, and other office-specific information. Caution: Extreme caution is required when using this option. 3. STORAGE to modify storage table relations (5E7 and later). This option is used to read or insert tuples of a storage table relation. Caution: Extreme caution is required when using this option. After entering STORAGE, the user will be prompted for a Storage Table Name. (Upon accepting a valid Storage Table Name, ODBE goes into the Enter Tuple Operation state.) 4. OVWTODD to overwrite data (5E6). This option is used when it is necessary to modify data in the ODD or Control ODD. Caution: Extreme caution is required when using this option. Misuse of this option could be SEVERELY detrimental to the operation of that particular processor on the switch. THIS OPTION SHOULD BE USED IN EMERGENCY SITUATIONS ONLY. In the Enter Tuple Operation state of ODBE, the user is prompted for the data operation to be performed. Valid tuple operations at this level depend on what was entered at the Enter Relation Name prompt. 1. If a valid relation name was entered, then the valid tuple operations are as follows: o I: Insert or add a new tuple. o R: Review or display a tuple. o U: Update or modify a tuple. o D: Delete or remove a tuple. o W: Write a tuple to a file. o BI: Batch Insert or add tuples from a file. Caution: Batch Insert of files larger than 1000 tuples must be split into smaller files. Large files can time out during processing, and also require RC/V logging to be inhibited. It is very important not to allow RC/V while logging is inhibited. o BR: Batch Review or output a relation to a file. o BW: Batch Write (write tuples into specified file). o VIRT: Display information about a virtual relation. (This command is only valid for virtual relations in 5E7 and later software releases). 2. If PARAMETER was entered, ODBE will prompt for the parameter name. After ODBE accepts a valid parameter name, the valid parameter operations are as follows: o R: Review or display a parameter. o U: Update a parameter. o BR: Batch Review parameters to a file. 3. If STORAGE was entered (5E7 and later software releases), the valid tuple operations are as follows: o I: Insert or add a new tuple. o R: Review (display a tuple without entering the generated key). o BI: Batch Insert (add generated key tuples from a file). o BR: Batch Review (output generated key tuples from a file). o GKR: Generated Key Review (display a tuple with the generated key specified). o GKVIRT: Display the parent relations of a storage table relation. 4. If OVWTODD was entered (5E6 software release), then the only valid tuple operation is the following: o ODDOVWT: ODD Overwrite (overwrites data in ODD or Control ODD). Tuple operations BI, BW, and BR prompt for the UNIX operating system filename in which to print the date or in which the data is stored. Tuple operations VIRT and GKVIRT print information to the terminal screen then prompt for another tuple operation. The tuple operation ODDOVWT prompts for the memory type, the ODD address, and associated data to be overwritten. For all other tuple operations, ODBE enters the Enter Primary Key state. In the Enter Primary Key state of ODBE, the user is prompted by name for the components of the key which uniquely defines a tuple in the relation. The only valid response to the Enter Primary Key prompt is a valid primary key value. Upon entering a valid primary key value, ODBE goes into the Enter Attribute Value state. In the Enter Attribute Value state of ODBE, the user is prompted for an attribute value by name. Possible responses to the prompt are as follows: o A valid attribute value. o A ``<'' to go back to the previous attribute. o A ``>'' to skip remaining items and complete whatever tuple operation you are involved in o A plus (+) to list attributes. This is the lowest level in ODBE. After entering the attribute values, the user may return to a higher level by entering an exclamation (!) or exit ODBE by entering a ``control-d''. ACCED is an interactive tool which allows the craft to manually locate, investigate, and correct data base corruption, and to reorganize hashed relations. Caution: Misuse of ACCED could result in premature exhaustion of data base memory. ACCED is invoked via input message RCV:MENU:ACCED or by typing the full path to ACCED from the UNIX system shell. ACCED can also be executed via the screen program (RCV:MENU:SCREEN) or MCC Page 194. Information on the screen program and MCC Page 194 can be found in Section .RM 3.11/ of this document. Upon access to ACCED, the craft enters into an interactive session of prompts and responses. Effective with the 5E7 software release, the ACCED tool is enhanced to include six data base utility operations: REVIEW, SCAN, OVERWRITE, DESTROY, REORG, and HASHSIM. The ACCED data base utilities allow craft to locate, investigate, and correct data corruption without manually performing the extensive, error-prone calculations required in the past. The HASHSIM operation is used for hashing simulation to determine optimal hashing parameters for reorganizing hashed relations. The enhanced ACCED gives the user capabilities to do the following: o Review head table, intermediate data pages (IDP), and data pages (DP) of a relation. o Review memory and disk office dependent data (ODD) by block ID or by address. o Review the run-time access dictionary for a relation, including past, current, future, and ODD versions. o Review information about a relation, such as its tuple size, tuple address, IDP information, and DP information. o Scan a relation for corruption by searching for unreadable tuples. o Overwrite one, two, or four bytes of data at a given memory or disk address. o Destroy an entire relation, an IDP in a relation, or a DP in a relation. o Manually reorganize relations of access types DBACC_GK and DBACC_HASH. o Simulate hashing a relation of access type DBACC_GK or DBACC_HASH to help determine optimal parameters for a manual reorganization. When ACCED is entered, the craft specifies one of the six data base utility operations. All six operations are permitted on the AM, SM, and the active side of the CMP. Only the REVIEW operation is available on standby CMP because ODD data on the standby side may not be current. Each operation, in turn, has its own submenu. The user interactively traverses ACCED's menu hierarchy to perform operations on the data base. Four concurrent ACCED processes can be run at any time in a processor (AM/SM/CMP). Following is an overview of each ACCED operation. Refer to AT&T 235-105-220, Corrective Maintenance Procedures, for additional information on ACCED operations and procedures for their use. When REVIEW is selected from the main menu, ACCED prompts the user for the relation name and the item to review. Following are possible things to review: o Head table: The head table option is displayed only for relations with head tables (all but 1-level indexed relations). When head table is selected for review, ACCED prompts for the starting relative address and number of bytes to review. The address is relative to the beginning of the head table, so address 0 (zero) is the start of the head table. Results of the review are dumped to the screen and routed to the ROP and Switching Control Center System (SCCS) if output message (OM) printing is on. o IDP or DP: The IDP option is displayed only for relations with IDPs (3-level indexed relations). When IDP (or DP) is selected for review, ACCED prompts for the intermediate data page number (or data page number), the starting relative address, and the number of bytes to review. The address is relative to the beginning of the IDP (or DP), so address 0 (zero) is the start of the IDP (or DP). Results of the review are dumped to the screen and routed to the ROP and SCCS if OM printing is on. o Access dictionary: When the access dictionary is selected for review, ACCED prompts for the version to review; current, any, or ODD. For current and ODD versions, the appropriate access dictionary is dumped to the screen and routed to the ROP and SCCS if OM printing is on. For any version, the craft must provide an index into the access dictionary array. The access dictionary of the given index is dumped. The craft can use this feature to dump the past version of the access dictionary (referred to as ``acc_bidx'' in the access dictionary) or the future version (referred to as ``acc_nidx''). o Data at a specified memory address: When data at a memory address is selected for review, ACCED prompts for the memory type, the starting physical address, and the number of bytes to review. It is important to note that the address is absolute. Results of the review are dumped to the screen and routed to the ROP and SCCS if OM printing is on. o Data within a specified memory block: When data within a memory block is selected for review, ACCED prompts for the block ID, the starting relative address within the block, the number of bytes to review, and the memory type. The address is relative to the beginning of the block, so address 0 (zero) is the start of the block. Results of the review are dumped to the screen and routed to the ROP and SCCS if OM printing is on. o Tuple information: When tuple information is selected for review, ACCED prompts for the tuple key of interest. ACCED supplies the following information for that tuple: IDP number, IDP address, IDP block ID, DP number, DP address, DP block ID, tuple address, physical tuple size, logical tuple size, and memory type. The IDP information is provided only for 3-level indexed relations. The information is dumped to the screen and routed to the ROP and SCCS if OM printing is on. When SCAN is selected at the main menu, ACCED prompts for the relation name, the starting IDP (if appropriate), and the starting DP. Then, ACCED begins reading tuples from that point until it reaches the end of the relation or until it finds a bad tuple. When data corruption is found, the following information is furnished for the corrupted tuple: IDP number, IDP block ID, DP number, DP block ID, tuple address, and physical tuple size. The IDP information is provided only for 3-level indexed relations. The information is dumped to the screen and routed to the ROP and SCCS if OM printing is on. When OVERWRITE is selected at the main menu, ACCED prompts for the memory type, the length of overwrite (one, two, or four bytes), the starting physical address, the current memory contents for that location and length, and the new data. The user must know the current memory contents before ACCED will permit the overwrite to continue. The results of the overwrite are dumped to the screen and always routed to the ROP and SCCS. It is important to note the following: 1. Recent Change (RC) must be inhibited before overwriting memory to avoid possible ODD splits. An RC can be inhibited by typing input message INH:RC. 2. The OVERWRITE operation is not logged for all processors, so an ODD backup is required immediately after the change. 3. OVERWRITE is permitted only on the active side of the CMP. To update the standby side of the CMP, a soft switch (which does a physical memory copy) is required immediately after the backup. When DESTROY is selected at the main menu, ACCED prompts for the relation name and for whether to destroy the whole relation, an IDP (if the relation is 3-level indexed), or a DP. If the whole relation is to be destroyed, then the head table block ID in its access method common dictionary is zeroed out. If an IDP is to be destroyed, ACCED prompts for the IDP number whose entry in the head table is subsequently zeroed out. If a DP is to be destroyed, ACCED prompts for the DP number whose entry in the head table (or IDP if 3- level indexed) is subsequently zeroed out. The DESTROY is reported to the screen and always routed to the ROP and SCCS. It is important to note the following: 1. Recent Change (RC) must be inhibited before destroying memory to avoid possible ODD splits. An RC can be inhibited by typing input message INH:RC. 2. The DESTROY operation is logged for the CMP so the standby CMP will be updated through continuous roll- forward. The DESTROY operation is not logged on processors other than the CMP. An ODD backup is required immediately after a DESTROY on all processors, except CMP. But, backup is recommended for all processors. When REORG is selected at the main menu, ACCED prompts for the relation name and checks to see if the relation is hashed (that is, access type DBACC_GK or DBACC_HASH). If the relation is not hashed, ACCED prompts for another relation name. If the relation is hashed, the access method common dictionary and dictionary for DBACC_GK or DBACC_HASH are displayed for the craft (they are not printed on the ROP). Then, ACCED asks if a hashing simulation is desired before manual reorganization is performed, and, if so, runs HASHSIM (described under Hashsim Operation, following). Whether or not HASHSIM is run, ACCED now prompts for the following reorganization parameters: foldtype (if relation not optimized), linear probe depth, head table size, data page size (DBACC_HASH relation only), and TMAX. Note: Data page size must not exceed 2 KB unless the physical tuple size is a power of 2. This guarantees that no tuple will cross a data page boundary which would violate the memory protection mechanism. ACCED first runs a conditional reorganization, that is, it looks to see if enough memory exists in the ODD segment to accommodate the reorganization. If enough memory exists, the reorganization continues. If there is a memory shortage, a warning message is displayed stating that ODD growth is desirable, and ACCED asks if an unconditional reorganization is desired. If so, a warning message is displayed stating that unconditional reorganization may fail, and reorganization continues. If reorganization succeeds, the access dictionaries that are dumped represent the new access dictionaries resulting from reorganization. If reorganization fails, no reorganization is done, and the access dictionaries that are dumped represent the access dictionaries that would have resulted from reorganization had it not failed. The access dictionaries are routed to the ROP and SCCS if OM printing is on. After an automatic reorganization failure, HASHSIM is used by the craft to determine optimal parameter values to be used in a manual reorganization of the relation. In this scheme, the craft is prompted to provide information about the relation to be simulated; such as the processor the relation resides on and the name of the relation. A batch review is performed to generate an American standard code for information interchange (ASCII) data file. Then, a file is generated that contains the folded keys of the relation. The newly created folded key file, along with some additional access dictionary information for the relation being simulated, will be made available to the UNIX system ACCED process to run the simulation. The additional access dictionary information specified by the craft through prompts include the following: (range of) maximum number of tuples (TMAX), (range of) data page sizes (for access type DBACC_HASH only), foldtype (nonoptimized relations only), and probe depth. Simulator output will be sent to the craft via the terminal or selectively to the ROP and will contain the following information about each simulation executed: o Tuple size used o TMAX value used o Data page size used o Head page size required o Number of data pages required for each stage in multistage hashing o TPAG value that was calculated o Number of tuples that would end up in overflow o Load factor o Average search time that would exist if these values were used in the manual reorganization of the relation o Maximum search time that would exist if these values were used in the manual reorganization of the relation o A score based on all these results. The craft would then evaluate those simulations having the lowest scores to determine which parameters should be used in the manual reorganization of the relation. Manual reorganization is a process by which the craft, using ACCED, can name a specific relation and attempt to reorganize it any number of times. ACCED has the same relationship with automatic reorganization that ODBE does to recent change. Caution: ACCED is an interactive tool which allows investigation, reorganization, or destruction of relations in the 5ESS switch data base. There is an automatic reorganization program which runs once a day to find and reorganize hashed relations which have gotten excessively into secondary overflow. When the automatic reorganizing program cannot resolve the overflow, it is necessary to use ACCED to reduce the overflow. When ACCED is used, it should be used by a person with sufficient technical training and detailed knowledge of the relational data base structure. Any misuse could result in premature exhaustion of the data base memory area. In manual reorganization, the craft can manually set rel_dsze (data page size), rel_hsze (head page size), and rel_tmax (maximum number of tuples) for a specific relation and try any number of times to reorganize (refer to AT&T 235-105-220, Corrective Maintenance Procedures). At times, it is useful to use manual reorganization on relations that hash poorly and cannot be reorganized easily. An RC_OEINFO cannot be reorganized automatically; it must be reorganized manually. The processor number must be ``193'' (in software releases 5E6 and later) when accessing RC_OEINFO via ACCED. Refer to AT&T 235-105-220, Corrective Maintenance Procedures, for a detailed overview and procedures for performing a manual reorganization of hashed relations via ACCED. The CNIDBOC is a menu-driven interactive UNIX system process which incorporates the Functional Listing, Recent Change (RC), and disk verification and modification of individual fields of RC structures. It is used by Common Network Interface (CNI) applications for emergency purposes, such as field troubleshooting or if the application's RC interface to CNI becomes inoperable. For 5E6 and later software releases, the CNIDBOC is accessed from the TLWS or RC/V terminal by entering the following input message: rcv:menu:cnidboc For 5E7 and later software release, the CNIDBOC also can be accessed from the screen program (MCC Page 194) by entering menu option ``c'' (Section .RM 3.11/, Screen Program User's Guide). AT&T 235-105-220, Corrective Maintenance Procedures, contains additional information on CNIDBOC and procedures for its use. Effective with the 5E9(1) software release, the Automated Circuit Pact Return Tag tool allows a user to display and print recent diagnostic faults and to interactively generate the Returned Circuit Pack Tag used in returning defective circuit packs to AT&T for repair. The Automated Circuit Pack Return Tag tool can be invoked as follows: o From the UNIX system terminal, enter "/usr/bin/rtag;" at the prompt. o From the TLWS terminal, enter "RCV:MENU:RTAG;" at the prompt. o From the MCC terminal, enter poke command 194 to access the screen program and then select option "r" RTAG. Also, a user can enter command "RCV:MENU:SCREEN;" to access the screen program. For detailed information about poke command 194 and the screen program, refer to Section .RM 3.11/ of this document. Procedures for using the Automated Circuit Pack Return Tag tool are documented in AT&T 235-105-220, Corrective Maintenance Procedures. This subsection contains information describing the application of a group of tools that can be useful for debugging and troubleshooting 5ESS switch software running on the AT&T 3B20 Duplex (3B20D) Computer. These tools offer a user the ability to view and change application text and data residing in the computer's processor, memory, and disks. Information is given on the use of the following tools: o BROWSE o File System Debugger (FSDB) o Generic Access Package (GRASP) o Ring Generic Access Package (RGRASP) o IBROWSE o IDUMP (interactive dump utility) o UPEDCUD [current update data base (CUD) and history file editor]. Caution: The tools described in this subsection allow changes to be made to low-level operations of the AM. Improper use of these tools can be service affecting. Before implementing any of the functionabilities provided, consult local supervision concerning policy. It is recommended that the implementation of any of these programs be discussed with the technical assistance organization prior to starting the procedure. The browse program is a data base debugger which allows a user to interactively peruse low-level access (LLA) data bases, formatted output of user data, and LLA internal structures. It is also used to: o Verify data o Find corrupted structures o Gather information o Repair damage. The support computer versions of browse examine files in the Software Demand Paging (SDP) address space format, files in loadf format, and ordinary files. The AT&T 3B20D computer version examines files in all of the previously mentioned formats and incore copies of loadf and ordinary files. Under the Bourne shell, the browse program is invoked by entering: browse [%][+-]name where: + indicates name is an ordinary file. - indicates name is a loadf file. % indicates named ordinary file or loadf file resides in core (AT&T 3B20D computer only). If name is not preceded by a + or -, name is in SDP address space format. If % is used, name must have one of the following forms: ecd pmdb <filename>,<index>,<segno> <segname>,<segno> where: ecd = ECD incore data base (segment name defined in header file <init_btdb.h>). pmdb = Plant measurement incore data base (segment name defined in header file <init_btdb.h>). filename = Segment names associated with the file system. index = Segment names associated with the file system. segname = A 32-bit number by which the system names segment. segno = Index of the segment in the virtual address space. The program has read only permission to the file, data base, or segment. Under the MML shell, the browse program is invoked by entering: RCV:MENU:DATA,BROWSE; The browse program may be invoked from any craft terminal except the MTTY or SCC. Specification of a data base is the same as in the Bourne shell but must be done via the browse command db (see Browse subheading, Printing, Subsection .RM 3.17.2.5/). Table .AW TL/ summarizes the invocation modes. Browse accepts commands from standard input as follows: <expr><cmd><str> An expression <expr> has the syntax shown as follows: <expr> :: <expr> <op> <expr> | <constant> | /<format> <values>/ | ?<format> <values>? | ( <expr> ) <op> :: + | - | * | / | % | , | ; <constant> :: <decimal digits> |0<octal digits> |0x<hex digits> |<char> |. |$ The operators and digit strings have their standard meanings. Because printing, searching, and division share the slash character, that character's use as an operator may require enclosure in parentheses to avoid ambiguity. A <char> is a C-language character representation as shown in the following chart. Therefore, '8'-060-o prints 010 because the value of character '8' is 070. ______________________________ | '\\0' | ' '| '@'| '_' | | '\\01' | '!'| 'A'| 'a' | | '\\02' | '"'| 'B'| 'b' | | '\\03' | '#'| 'C'| 'c' | | '\\04' | '$'| 'D'| 'd' | | '\\05' | '%'| 'E'| 'e' | | '\\06' | '&'| 'F'| 'f' | | '\\07' | '\\'| 'G'| 'g' | | '\\b' | '('| 'H'| 'h' | | '\\t' | ')'| 'I'| 'i' | | '\\n' | '*'| 'J'| 'j' | | '\\013 | '+'| 'K'| 'k' | | '\ | ','| 'L'| 'l' | | '\\r' | '_'| 'M'| 'm' | | '\\016'| '.'| 'N'| 'n' | | '\\017'| '/'| 'O'| 'o' | | '\\020'| '0'| 'P'| 'p' | | '\\021'| '1'| 'Q'| 'q' | | '\\022'| '2'| 'R'| 'r' | | '\\023'| '3'| 'S'| 's' | | '\\024'| '4'| 'T'| 't' | | '\\025'| '5'| 'U'| 'u' | | '\\026'| '6'| 'V'| 'v' | | '\\027'| '7'| 'W'| 'w' | | '\\030'| '8'| 'X'| 'x' | | '\\031'| '9'| 'Y'| 'y' | | '\\032'| ':'| 'Z'| 'z' | | '\\033'| ';'| '['| '{' | | '\\034'| '<''| '\\'| '|' | | '\\035'| '='| ']'| '}' | | '\\036'| '>'| '^'| '~' | | '\\037'| '?'| '_'| '\\177'| |_______|______|______|________| An item enclosed in slashes (/) is the next address with given values; an item enclosed in question marks (?) is the previous address with the given values; wraparound applies to searching in both directions. Therefore, /d 8/ locates the next short integer, 8. The previous integer 8 is located with ?d 8?. The value does not have to match the format: /d 010/ locates the next 8. The value can also be an expression; for example, /d '8'-060/ also locates the next 8. An empty <format><value> list refers to the list specified previously. The dot (.) is the current address; the dollar sign ($) is the number of bytes in the file or address space. (Because browse addressing is zero based, $-1 is the highest address.) Evaluation is left-to-right, with the only precedence established by parentheses. All computations are performed with long operands. A slash (/) following an expression prints data base information at the address equal to the value of the expression. The address formats following the slash control printing and have the syntax shown as follows: <aformat> :: <item> | <item> <aformat> <item> :: <term> | <count> <term> <term> :: ( <aformat> ) | [ <aformat> ] | < <aformat> > | { <aformat> } | <byteformat> | <memformat> | <numformat> | <specialformat> | <userformat> | "any characters" <byteformat> :: 'a | 'c | 'd | 'o | 'u | 'x | b | c <memformat> :: .<C structure member identifier> <numformat> :: D | d | I | i | O | o | U | u | X | x <specialformat> :: A | B | C | H | L | Q | R | S | T | r | s <userformat> :: E | F | G | J | K | M | N | P | V | W | Y | Z <count> :: Positive decimal number The format letters and grouping characters have the meanings shown in Tables .AW TM/ and .AW TN/, respectively. Format items enclosed in parentheses[( )] establish the scope of a count. A count in front of an item is equivalent to repeating that item the given number of times. For example, 2(DX3(bc)) is equivalent to DXbcbcbcDXbcbcbc. Format items enclosed in square brackets ([ ]) indicate that the item refers to an address offset from the start of the current record. The square brackets are useful for display of variable length data definition language (DDL) constructs (vectors and strings), which are stored offset from the fixed portion of a record. Format items enclosed in corner brackets (< >) suppress the printing of their corresponding values. For example, to examine the first three characters of a 10-character array and the following integer, use ./3c<7c>d. Format items enclosed in braces ({ }) apply the format to the address given by the value at the current address. Thus, /R prints a record header at the current address; /{R} prints a record header indirect from the current address. The equal sign (=) prints in I format the current location (that is, current address plus current offset). Therefore, the command ./100(5X"\\n"=":\\t") prints 100 lines of hexadecimal dump format, and each line is preceded by the address of the first word on the line. Nonreserved capital letters (those in <userformat>) may be given definitions. For example, stating J DbbX defines a new format J which prints a long decimal, two bytes, and a long hexadecimal. The reserved format I is also settable. You may examine ITEMIDs in decimal, octal, unsigned, or hexadecimal by setting I to D, O, U, or X, respectively; the initial format is hexadecimal. The I format also controls current address printing, the i format, and ITEMID fields in structures. The format associated with K applies to the key portion of the buckets of hash and btree access methods; the initial format is nb, where n equals KEYMAX, the LLA #define constant giving the maximum storage allowed for keys. If the K format is empty, then the B and T formats print only the bucket and node headers, respectively. In this instance, the T format indents the headers to reflect the depth of each node in the tree. Arithmetic and character formats print individual bytes. The formats d, 'o, and 'x print a byte in decimal, octal, and hexadecimal, respectively. The b format prints a byte in the last arithmetic byte format entered; the initial format is octal. The formats 'a and 'c print a byte in ASCII mnemonic form and C-language form, respectively. The ASCII mnemonics are those established in the file /usr/pub/ascii. The c format prints a byte in the last character format entered; the initial format is ASCII mnemonic (see the following chart). ___________________ | nul| sp| @| _ | | soh| ! | A| a | | stx| " | B| b | | etx| # | C| c | | eot| $ | D| d | | enq| % | E| e | | ack| & | F| f | | bel| ' | G| g | | bs | ( | H| h | | ht | ) | I| i | | nl | * | J| j | | vt | + | K| k | | np | , | L| l | | cr | - | M| m | | so | . | N| n | | si | / | O| o | | dle| 0 | P| p | | dc1| 1 | Q| q | | dc2| 2 | R| r | | dc3| 3 | S| s | | dc4| 4 | T| t | | nak| 5 | U| u | | syn| 6 | V| v | | etb| 7 | W| w | | can| 8 | X| x | | em | 9 | Y| y | | sub| : | Z| z | | esc| ; | [| { | | fs | < | \\| | | | gs | = | ]| } | | rs | > | ^| ~ | | us | ? | _| del| |____|____|___|_____| Browse echoes literal text between double quotes ("). The backslash (\\) affects the escape sequence shown in Table .AW TO/. Browse prints strings with the s format using the same conventions. A slash (/) following an expression causes data base information to print at the address equal to the value of the expression. The formats following the slash control printing. Printing data base information depends on two automatically calculated values: the current address and the current offset. Each format item prints the information at its target location, which is the current offset from the current address. A slash following an expression establishes the value of the expression as the current address and sets the current offset to zero. Generally, each format letter increments the current offset by the number of bytes it prints (Table .AW TM/), and a carriage return alone increments the current address by the current offset. The effect of these computations is that stringing together format items prints sequentially through the data base. An example formatted printout is shown in Figure .AW G84/ which illustrates printing seven items starting at address 100. Browse prints the address followed by a colon (:) and then the information from the data base in the indicated format. The vertical lines in the diagram show the relationship between format item and printed value. Pressing carriage return again yields: 114: 692 11 xc1 b c d e if the fields starting at 114 have values one more than their corresponding fields starting at 100. Four exceptions to the description of address calculations are as follows: o Linked structures buckets, rid blocks, queues/stacks, and sets (formats B, L, Q, and S, respectively): In these formats, the computation of the current offset is made so that the next item printed is the next structure on the linked list, not the next sequence of logically contiguous bytes. If 044 is the address of the first set, the command 044/3S prints the first three sets. Use right recursive format definition for these formats. If J is defined as SJ, the command 044/J prints all the sets. o Items in square brackets or braces: The items within square brackets are used to calculate a new target location offset from the current record by the value in the target location. To get a current record, use R format. The items within braces are used to calculate a new target location at the address given the current address itself. Printing begins at the new target location obtained by the indirection. The altered offset has effect only within the brackets or braces. An item enclosed in brackets is treated as having length sizeof(int); an item enclosed in braces has length sizeof(ITEMID). Figure .AW G85/ is an example of a location printed with R format. It indicates that the user area of the record begins at address 100 in the data base. The [2c] prints two characters at offset 10 (the value at 104) from address 100 (the start of the record). The format item X following the [2c] resumes printing at 106 as though the bracketed item were a simple integer field. In this example, the command 100/{c}[2c]X4c is equivalent to the consecutive commands 691/c and 104/[2c]X4c. The indirect formats are useful for printing LLA vectors, which consist of fixed and variable portions. The variable portions are located at positions determined by the fixed portion. o Btree access method (format T): The T format prints (in depth-first order) the subtree with root at the current address. The T format changes neither current address nor current offset. o Formats for symbolic record printing: If an r2a process is started via the dd command, then at the address of a record, the r format prints all record members and their values. A dot (.) followed by a name prints only the names and values of record members with matching names. In either case, current address and offset are not affected. Browse commands take the following form: <expr> <command> <parameters> In the following list, default addresses are enclosed in braces and are not part of the command. < [name] The < command causes browse to interpret a trailing string as a filename from which input is accepted. If the command itself appears in the named file, browse places the new file on a stack and switches input to the new file. An end of file (EOF) pops the stack. A missing name causes a switch to standard input. > name The > command interprets a trailing string as a filename or a shell command to which standard output is directed. If the trailing string starts with an !, then it names a shell command; otherwise, a file. The special name stderr redirects output to stderr instead of to a file. If the trailing string is omitted, output returns to standard output. An interrupt redirects output to standard output unless a previous redirection was to stderr. >> name The >> command is the same as >, except that output is appended to the file. {.}/<formats> The `` / '' command prints the locations in the data base starting at the given address in the given formats. Available formats are given in Table .AW TM/ along with the number of bytes each represents. {.}#/<formats> <value list>/ The patch command substitutes the values in the given list in the indicated formats for the values at the given address. The value list is a space- separated list of expressions, each of which must correspond to a printing item in the format. The s format patches a number of bytes equal to the length of the string following the format. For a patch, browse prints: <addrs>: <old value list> <- <new value list> The format letter controls message printing. The s format patches a variable number of bytes and care must be taken with its use. {last}=<format> An equal sign (=) between an expression and a format controls expression value printing. The format may be any letter in <pformat> except s. In the character format, non-ASCII values are printed in octal; ASCII characters are printed either as C-language constants or as ASCII mnemonics (depending on the last given 'a or 'c format). An octal format forces a leading zero in the print; a hexadecimal format, a leading 0x. Thus, 4+6*2=x prints 0x14. !<string> Submits the string to the shell. <cap> [string] Capital letter commands associate the letter with the trailing string. Appearances of the capital letter in formats are replaced by the associated string. The replacement is recursive; appearances of defined capitals may appear in other capital commands. Left or circular recursion in formats leads to disaster. If the trailing string is omitted, the current value of the macro letter is reported; if the string is whitespace, the macro is cleared. db [name] If a name follows the data base command, then browse disconnects any currently attached data base and attempts to attach the named data base with no permission to patch. If no string follows the db command, then the currently attached data base name and its access permissions are printed. [The code (#) indicates permission to patch.] dbp [name] If a name follows the data base patch command, then browse disconnects any currently attached data base and attempts to attach the named data base with permission to patch. If no name follows the dbp command, then browse toggles the access permission of the currently attached data base. In either case, dbp reports the currently attached data base and its access permissions. dd [name][tabstops] If a name follows the data dictionary command, then browse starts the named dictionary process. This process, which must be generated by record to ascii program generator (r2agen), provides symbolic information about records. With a data dictionary process, the user may print entire records by member name and value via the r format, print single or related sets of record members with their values via the .name format, and patch single record members by name. The data dictionary process also augments the R, S, and A formats by including the record, set, and access method names, respectively. The name may be followed with a number, interpreted as the number of tab positions after which to place values. This number is helpful in formatting values in record prints. If the dd command is not given a name, then it reports the name and tab stop of the current process. The data dictionary processes that are available for use with the ECD and SG data bases are ecd-aux and sg-aux, respectively. files Reports the stack of input files, most recent last. frame size Sets the frame size for the internal pager. For an SDP address space, the frame size must be a multiple of the page size with which the space was generated. g/<formats> <value list>/<command> The global command searches the addresses in the data base which have the given values and performs the given command at those addresses. More than one command may be given on succeeding lines if a backslash terminates the previous line. The value list is a space-separated list of expressions, each of which must correspond to a printing item in the format. The delimiting slashes may be uniformly replaced by any other character except backslash. For example, g/X<4c>d 0x210 6/ .+8#/d 8/ looks for addresses that contain a long 0x210, any four characters, and a short 6. It then patches the 6 to an 8. Note that there are two printing formats (X and d) and two values (0x210 and 6). Because the values may be expressions, the 0x210 of the previous example could be replaced by (256*2)+16. h Reports the address of the LLA header structure. help Prints a summary of commands and formats. macinfo Reports the values of the user-settable format letters. q Disconnects a currently attached data base and exits. A q command is equivalent to an end of tape (EOT) (control-d) when there are no files from a < command on the input file stack. r/<formats> <value list>/<command> Given a trailing string composed of a format and a list of values, the record command searches the data base for the occurrence of values in a record and executes the given command when a match is found. The match is located at the beginning of the record. Multiple commands may be given on succeeding lines when the previous line ends in a backslash. The formats and values are the same as in the global search request. The default command prints the RIDs of matching records; an empty format/value list matches any record. Therefore, the command "r /r" matches all records (the first r) and prints (/) them symbolically (the second r). The following error messages result from improper commands and do not terminate the browse session. All other messages are fatal and result from internal or other errors from which there is no recovery (for example, inability to read a file after a proper and successful open). ``bad alignment'' illegal data-type alignment (for example, int at odd address) ``bad byte format'' format letter following ' not a,c,d,o,u,x ``bad expression'' illegal expression construction (for example, missing operand) ``bad format'' illegal format (attempt to set I to other than D,O,U,X; bad count field, attempt print from nonmacro letter) ``bad frame size'' frame size not a multiple of page size ``bad grouping'' (), [], <>, or {} not balanced ``bad id'' address negative ``<adrs> : bad id'' address out of bounds ``bad operand'' nonnumeric operand in expression ``bad recdisp information'' incorrect information from auxiliary process ``bad segment specification'' incorrect segment specified for incore attach ``bad string'' string does not begin with a " ``can't allocate frames'' frame size too large ``can't connect <name>'' data base <name> nonexistent or no permissions to <name> ``can't establish pipe'' cannot get pipe descriptor for ! command ``can't execute'' cannot execute named auxiliary process ``can't fork dd process'' fork failed before execution of auxiliary process ``can't fork'' cannot fork before execution of process named in ! command ``can't get segment'' getseg call failed on incore segment ``can't malloc space for search'' search command too complicated ``can't open file'' cannot connect to named file with + ``can't open input pipe'' cannot get pipe descriptor for <! command ``can't open input file'' trouble getting to command file for input ``can't read control structure'' cannot connect to file as a loadf file ``can't read control structure'' cannot connect to file as a loadf file ``can't read in get_c'' trouble with auxiliary process ``can't seek in data base'' file or loadf file corrupted ``can't seek to control structure'' bad loadf file ``dd process out of sync'' nonsense messages from auxiliary process ``id out of range'' address greater than file size ``improper value list'' value list in search or patch not of form /<formats><values>/ ``line too long'' command line more than 80 characters ``lost out child'' a process spawned by the ! command has disappeared ``missing value list'' no values follow formats in search or patch command ``no closing <char>'' delimiters not balanced in search or patch command ``no data dictionary process'' the r format requires an auxiliary process ``no data base attached'' a command requires a data base for its completion ``no match'' search failed to find values ``no permission to patch'' patch command attempted before dbp command issued ``no remembered command'' !! given before !<command> ``no remembered search string'' // given before /<format> <value list>/ ``non-C character constant'' a C-character constant not enclosed in single quotes (') ``read error after fork'' auxiliary process gives/sends bad initial information ``search unsuccessful'' search command failed to find values in data base ``<adrs> not bucket'' structure at <adrs> not a bucket ``<adrs> not a head'' structure at <adrs> not a dml header ``<adrs> not rec head, not indirect to one'' <adrs> not a RID ``<adrs> not a rid block header'' structure at <adrs> not a rid block ``<adrs> not queue or stack'' structure at <adrs> not an access method queue or stack ``<adrs> not set header'' structure at <adrs> not a set ``shared SDP not supported'' cannot connect with %<name> ``too many input files'' system limit reached on open input files ``unable to get segment code'' data base not associated with segment name ``unable to open <name> for getseg'' data base <name> nonexistent or no permissions to <name> ``unable to open output file <name>'' > or >> command unable to open or create file ``unbalanced patch delimiter'' delimiters on /<format> <value list>/ in patch command not balanced ``unknown character format'' encountered byte format other than 'a,'c,'d,'o,'u,'x ``unknown enum name'' auxiliary process has incorrect enumeration name list ``unknown reply'' auxiliary process sends incorrect initial information ``unsupported member type for formatted patch'' patching with auxiliary process is restricted to the following types: char, enum, int, link, long, owner, short, string, unsigned ``wrong packet type in get_c'' bad communication from auxiliary process ``zero or negative record length'' bad communication from auxiliary process Warning: The fsdb should NEVER be used on a mounted file system unless absolutely necessary, and it should not be used on any file system that the user cannot afford to lose completely! When modifying a mounted file system it is necessary to modify BOTH the disk copy and any related global data maintained by the File Manager (FMGR). It is virtually impossible to be CERTAIN that everything has been modified correctly. Failure to CORRECTLY modify BOTH the FMGR and the disk copy of the file system may necessitate a system reboot, a boot from backup, or a complete Load Disk From Tape (LDFT) procedure. The fsdb command is a tool which provides a convenient means of examining and correcting data within a file system, special device type file, such as /dev/vtoc, or any file. Contained in fsdb are conversions that translate block and i-numbers into their corresponding disk addresses. Also included are mnemonic offsets which are used to access different parts of an i-node. These features simplify correcting control block entries or descending the file system tree. The fsdb is normally invoked through the UNIX operating system shell by specifying the command name, fsdb, followed by the name of the file system or special device file to be examined. For example, to examine the ``etc'' file system, the command would be as follows: fsdb /dev/etc <return>. If the target for examination is a special device file such as /dev/vtoc, fsdb must be invoked as follows: fsdb /dev/vtoc - <return>. Several error checking routines to verify i-node and block addresses are contained in fsdb. These are disabled, if necessary, by invoking fsdb with the optional ``-'' argument or by using the 0 symbol. (The fsdb reads i-size entries from the superblock of the file system in order to perform these checks.) In the command for examination of a special device file (see previous example), the ``-'' at the end of the input string disables error checking. This is necessary because vtoc is not a file system, so there is no superblock for fsdb to read. Numbers are considered decimal by default. Octal numbers must be prefixed with a zero (0). Hexadecimal numbers must be prefixed by either x or 0x and must be terminated with a colon (:). During any assignment operation, numbers are checked for a possible truncation error due to a size mismatch between source and destination. Since fsdb reads a block at a time, it handles both raw and block I/O. A buffer routine retains commonly used blocks of data and reduces the number of read system calls. Some assignment operations result in a delayed write-through of the corresponding block. The symbols recognized by fsdb are as follows: i Converts from i-number to i-node address. b Converts to block address. d Directory slot offset. +,-,*,/ Address arithmetic. q Quit. >,< Saves, restores an address. new-line Increments current address. = Numerical assignment. Note: This symbol must be entered without spaces, and the assignment must be terminated with a colon (:). += Incremental assignment. -= Decremental assignment. =" Character string assignment. 0 (zero) Error checking flip-flop. p General print facilities. f File print facility. B Byte mode. W Word mode. S Half-word mode. ! Escapes to shell. The print facilities generate a formatted output in various styles. The current address is normalized to an appropriate boundary before printing begins. It advances with the printing and is left at the address of the last item printed. To terminate the output at any time, use the delete character. If a number follows the p symbol, that many entries are printed. A check is made to detect block overflows since logically sequential blocks are generally not physically sequential. If a count of zero is used, all entries to the end of the current block are printed. These print options are available: i Prints as i-nodes. d Prints as directories. o Prints as octal half-words. e Prints as decimal words. c Prints as ASCII characters. b Prints as hexadecimal bytes. h Prints as hexadecimal words. The f symbol prints data blocks associated with the current i-node. (Blocks are numbered starting with zero.) The desired print option letter follows the block number, or the f symbol. Checks are made for special devices and for nonzero block pointers. Dots, tabs, and spaces are used as function delimiters but are not necessary. A line containing only a new-line character increments the current address by the size of the data type last printed. That is, the address is set to the next byte, word, half-word, directory entry, or i-node, allowing you to step through a region of a file system. Information is printed in a format appropriate to the data type. Bytes, words, and double words are displayed with the hexadecimal address followed by the value in the hexadecimal and decimal. The symbol '.B' or ' is appended to the address for byte and half-word values, respectively. Directories are printed as a directory slot offset followed by the decimal i-number and the character representation of the entry name. I-nodes are printed with the labeled fields describing each element. The following mnemonics are used for i-node examination and refer to the current working i-node: md Mode. ln Link count. uid User ID numbers. gid Group ID number. sz File size. a# Data block numbers (0-7). at Access time. mt Modification time. maj Device class number. min Logical device ID number. The following are examples of fsdb command use: 386i Prints i-number 386 in an i-node format. This now becomes the current working i- node. ln=4 Changes the link count for the working i-node to 4. ln=+1 Increments the link count by 1. falc Prints, in ASCII, block one of the file associated with the working i-node. a0b.p0x10:h Prints the first 16 words of the file in hexadecimal for which a0 is the starting block number. 2i.fd Prints the first 32 directory entries for the root i-node of this file system. d5i.fc Changes the current i-node to the i-node associated with the fifth directory. The first 512 bytes of the file are then printed in ASCII. 1b.p0o Prints the superblock of this file system in octal. 2i.a0b.d7=3 Changes the i-number for the seventh directory slot in the root directory to 3. (This example shows how several operations can be combined on one command line.) d7.nm="name" Changes the name field in the directory slot to the given string. Quotes are optional when used with nm if the first character is alphabetic. GRASP in the AT&T 3B20D computer is a single-user utility system and is a subsystem of the software release of UNIX Real-Time Reliable (RTR) operating system software. The GRASP tools allow software maintenance personnel to observe the behavior of UNIX RTR operating system software in an operational environment. GRASP aids in the analysis of software faults and is a means of observing the flow of system software in order to isolate software bugs. It is intended to be used to gather information on known problems rather than to detect or correct problems. GRASP is controlled by input from any maintenance terminal or from the SCC. GRASP output appears on the ROP and on the controlling (INPUT) terminal. Caution: Although GRASP can be used by the craft, care should be exercised. Improper use of GRASP can result in program mutilation or excessive utilization of system resources. GRASP capabilities consist of the following: o Data Transfer Functions: The COPY, DUMP, and LOAD commands allow the user to move, print, and write data to addressable system locations. o Breakpoints: The WHEN command allows the user to execute instruction and perform utility functions when the program flow reaches or matches a specified condition. o Breakpoint Manipulation Commands: These commands allow the GRASP user to create, enable, disable, view, and remove breakpoints. o Override Commands: These commands enable the user to override GRASP default time limits. o Trace: The primary function of the trace feature is to indicate the flow of execution around a target event; for example, branch instruction. GRASP uses the UN615 dual access utility circuit (DUC) or the UN21 utility circuit (UC) hardware to access the AT&T 3B20D computer. Breakpoint functions appear the same with either the DUC or UC. If the DUC or UC is not installed in the AT&T 3B20D computer, fails during use, or the Field Test Set (FTS) is installed, GRASP clears all affected breakpoints and invalidates the trace mechanism. All other GRASP features are still available. In addition, GRASP rejects all new breakpoint/trace definitions that would require DUC or UC. Note: The FTS is a separate debugging processor that can be connected to the DUC only. When the FTS is connected, it appears to the computer that the DUC is not installed. When a working utility circuit is reinstalled, GRASP must be notified of the change by the INIT:UC input message. After receipt of this input message, GRASP again allows trace and hardware breakpoint definitions. In UNIX RTR Operating System, Release 6, the enhanced GRASP (EGRASP) feature is available in the AT&T 3B20D computer. This feature is provided as an alternative to the FTS for real-time software debugging. EGRASP is a resident software package that provides on-line real-time software debugging capabilities. It supports an interface to the UN615 DUC to provide all of the existing GRASP functions, in addition to the new trace and matching functions. It also provides the capability to place multiple breakpoints in code, to read and write memory registers, and to dump the contents of memory. All GRASP command examples given here are in Man Machine Language (MML). Table .AW TP/ lists the 5ESS switch input messages that move, print, and with certain restrictions, write data into any addressable location in the system. See the UNIX RTR Operating System Input/Output Messages Manuals for details on any specific input message and for system responses. Breakpoints detect the existence of a set of specified conditions on the machine. The definition of a breakpoint has two parts: (1) description of conditions that are to be matched and (2) list of actions (maximum of five action clauses) to take place when the match occurs. The WHEN command starts a list of GRASP commands that are performed when a specified breakpoint condition exists. The list must be terminated with the END:WHEN command which is not counted as a part of the action list itself and does not count against the limit of five action clauses. (In MML, the complete list of WHEN commands is terminated with a semicolon``;''. Individual clauses within the list are terminated with an exclamation point ``!''.) After a WHEN command, with its conditions and action list, is entered successfully, the breakpoint is assigned a number by GRASP. The breakpoint is then referred to exclusively by its number. Up to twenty different breakpoints can be defined in the system at any time. The numbers assigned to breakpoints during a debugging session are not reused. However, the RESET option to the CLR:UTIL command is used to restart the breakpoint number at one after clearing the currently defined breakpoints. GRASP prints two output messages in response to a breakpoint definition after the print follows (PF) is given. The first message assigns a number to the breakpoint. This message should appear soon after the PF. The second message confirms that the breakpoint was set up successfully or indicates that the breakpoint was aborted and gives the reason. This should occur within one minute. When a breakpoint fires, its action list is executed sequentially. The INH:UTILFLAG ME command, if used, can be anywhere in the work list without affecting the rest of the actions being executed in the action list for that firing of the breakpoint. A count of the number of times the breakpoint has fired is kept. Each time the breakpoint fires, FIRENUM increases by one. All output generated by the action list is labeled with the breakpoint number and the firing number as shown in the following example. Breakpoint Definition WHEN: UID=h'112, ADDR=h': W! DUMP: REG=PA! DUMP: ADDR=h'20130! END: WHEN; Output Produced When Breakpoint Fires REPT GRASP BREAKPOINT FIRED UTILID = h'112 PID = ________ BREAKPOINT = 1 FIRENUM =1 REGISTER: CONTENTS(h'): PA: h'00005286 DUMP REG COMPL #G1 ADDRESS(h'): CONTENTS OF MEMORY(h'): 20130: 0000016A DUMP ADDR h'20130 COMPL #G2 Breakpoints that fire on execution of an instruction are called software breakpoints because of the way they are implemented. The breakpoint itself is an instruction that transfers control to GRASP when it is executed. See the UNIX RTR Operating System Input Messages Manual, (303-082, MML) WHEN:UID or WHEN:PID (Generic 2) for details. One exception is when the action list contains any command that controls or affects the transfer trace (see Transfer Trace in Section .RM 3.17.4.7.2/). When the transfer trace is affected, the breakpoint is implemented in hardware rather than software. Starting the transfer trace is implemented in software for execution (EXC) breakpoints. Software breakpoints are set up [at the location specified by the utility identification (UID) or process identification (PID), and ADDR keywords of the WHEN command] as soon as possible after the breakpoint is defined. The OPCODE itself is not changed until the breakpoint is allowed. Processes are described by the UID or PID and, in some cases, a user process name. However, more than one process can be active with the same UID and process name. When this happens, GRASP sets up the first breakpoint in one of the matching processes at random. If another breakpoint is defined for the same UID or process name, GRASP sets up the breakpoint in the same process as the first. If a process on the machine does not match the described conditions, the breakpoint is not set up. However, some commands (listed in Table .AW TP/ and labeled ``immediate'') can be used outside a breakpoint. The OPC parameter is required on software breakpoints to ensure that the user knows what he is doing. Severe problems occur if a breakpoint is accidentally set up in the data portion of an instruction. When the breakpoint is set up, the second of the breakpoint messages is actually printed. The message indicates either that the breakpoint was set up successfully or, if unsuccessful, the reason for its failure. Because the breakpoint OPCODE is not placed until the breakpoint is allowed, an inhibited software breakpoint does not fire and does not use any machine resources. Because of the way software breakpoints are implemented, the breakpoint fires before the instruction where it is placed executes. The instruction in the original text is saved before it is overwritten by the breakpoint instruction. Only after the breakpoint fires and the action list is executed, is the displaced instruction executed. Execution then resumes with the instruction following the displaced one. For hardware implemented breakpoints, the breakpoint fires after the instruction where it is placed executes. Table .AW TQ/ summarizes the breakpoint implementation types (H - hardware, S - software), which depend on two factors: breakpoint mode (EXC - execution, R - read, W - write, or RW - read write) and the presence or absence of trace commands in the action list. Breakpoints that fire on accesses of data are implemented with hardware using matchers on either the UN21 UC, UN61 DUC, or UN615 DUC. Hardware breakpoint functions appear, to the user, to be identical with either the UC or DUC. To set up a hardware breakpoint, GRASP configures the matchers that are needed and supplies the values that are to be matched. The circuitry continually compares the values with what is taking place on the machine. If the breakpoint is enabled, the breakpoint fires when all the matchers specified during setup match. If a hardware breakpoint is disabled, the hardware passively tries to match but does not interrupt processing on the machine. Disabled hardware breakpoints do not use any resources of the machine. Because the amount of hardware on the utility circuit is limited, a maximum of four hardware breakpoints can be defined at one time. Because the trace also uses hardware matchers, fewer breakpoints are available while a trace is defined. If the particular matchers needed are not available, it is possible to have fewer than four hardware items defined but have a command rejected for lack of resources. This is generally true when using an address range. Only one matcher on the utility circuit can be set up to match on a range of addresses. A second command requesting an address range is rejected even though a breakpoint using a single address is accepted. Following is a hardware breakpoint example and the resulting system response. See the appropriate input or output message in AT&T 235-600-700 or AT&T 235-600-750, Input Messages Manual and Output Messages Manual, respectively, for specific details. Breakpoint Definition WHEN:PID=65536, ADDR=h'A0000 - h'A00FF ;RW! DUMP:REG=PA! END: WHEN! System Response WHEN PID 65536 ADDR X'A0000 STARTED HARD 18 #G5 WHEN PID 65536 ADDR X'A0000 COMPL DISABLED 18 #G6 A breakpoint can be defined to fire upon receiving an active external event backplane signal. This is implemented using a hardware trigger and the DUC matcher. If the condition matcher is already being used for a trace, a trigger allocation error results if an attempt is made to define a condition breakpoint. The condition breakpoint fires immediately upon receipt of the external event regardless of an executing process. The processor can in fact be idle when this occurs. In this event, any register copy and load commands inside the breakpoint action list deal directly with the current machine registers, which may be of limited value. If a process is running when the breakpoint fires, register copy and loads deal with the saved values of the interrupted process. This feature would be most useful when some external analysis equipment, such as a logic analyzer, triggers the event. The breakpoint will continue to fire if not inhibited inside the action list as long as the external event signal is active. Following is a condition breakpoint example and the resulting system response: Breakpoint Definition WHEN:COND=E! DUMP:REG=PA! INH:UTILFLAG=ME! END:WHEN; System Response WHEN COND E STARTED HARD 1 #G5 WHEN COND E COMPL DISABLED 1 #G6 Breakpoints can be allowed or inhibited from firing, their definitions can be cleared, and a summary of all breakpoints can be printed. The commands to manipulate breakpoints are given in Table .AW TR/. See the appropriate input or output message in AT&T 235-600-700 or AT&T 235-600-750, Input Messages Manual and Output Messages Manual, respectively, for details on any specific input message and for system responses. The input message, IN:DTIME, overrides the GRASP default dynamic real-time limit. See the appropriate input or output message in AT&T 235-600-700 or AT&T 235-600-750, Input Messages Manual and Output Messages Manual, respectively, for details on any specific input message and for system responses. If GRASP uses all of the time it is allowed according to the value of the dynamic real-time limit, an output message is printed indicating that all GRASP breakpoints were inhibited. The breakpoints must be selectively reallowed. The output message REPT GRASP DYNAMIC RESET indicates that a GRASP real-time limit override has expired and has been reset to the normal installation default value. GRASP supports a trace feature which permits the user to record and view the flow of program execution on the machine. The trace can be used in either of two ways: (1) to record the events leading to a target event or (2) to record program flow following a target event. Note: The trace memory for the DUC is larger than the memory for the UC. The UN615 DUC holds 8192 entries, the UN61 DUC holds 2048, but the UC holds only 256 entries. This section describes trace states and transitions, discusses trace hardware issues, and gives details on trace options. States and Transitions The five operations available to trace program flow and the commands to implement these operations are shown in Table .AW TS/. Any of these operations can be done as immediate operations. Only the commands to start and stop the trace are allowed in breakpoint action lists. The trace can be in any one of the following states: o Undefined o New o Running o Stopped o Dumped. Before any trace command is executed, the trace state is checked and the command is rejected if it is logically incorrect for the trace state. The allowed transitions are shown in Figure .AW G86/. For trace commands in breakpoint action lists, only minimal state checking is done when the breakpoint is defined. A command to start the trace is rejected if the trace is undefined. The full state check is done only at the time the breakpoint fires and the action list is executed. Rejected trace commands do not affect the rest of the action list processing. The trace operations fall into two classes, slow and fast, according to the amount of data they move to or from the utility circuit. The slow operations initialize the trace and dump its memory. These operations currently take over 20 milliseconds and are performed at execution priority level 3. The other operations are fast and add little time when used in breakpoint action lists. Hardware Issues The trace is controlled by one of four utility circuit triggers depending on trace type. As long as a trace is defined, one of the utility circuit triggers is unavailable for breakpoints. The trigger used is also the one that allows a range of data addresses to be matched. When a trace is defined, the range matcher is unavailable and vice versa. This special trigger is marked with an asterisk in the output from the OP:UTIL input command for easy identification. Hardware implemented execution breakpoints differ from software implemented execution breakpoints in one respect. That is, the breakpoint action list for a software implemented breakpoint is executed before the instruction where the breakpoint is set up. For a hardware implementation, the action list is executed after the instruction. This should be kept in mind when defining the breakpoint and interpreting its output. Because only one matcher that traps the execution of an address is available on the utility circuit, only one execution breakpoint that controls the trace can be defined at one time. Starting a trace from an execution (EXC) mode breakpoint allows control of the transfer trace with two execution breakpoints. In summary, when a trace is defined: o The data access range matcher is unavailable for breakpoints. o Only three data access breakpoints (at most) can be defined depending on trace type (two if an execution breakpoint controls the trace). Trace Options Several options are available to tailor the exact type of information that is recorded in the trace memory. These options are described in the following paragraphs. UID Trace With this type of trace, the output indicates every process switch including those to the kernel and the special processes. For more details on how to read the trace output, see the Subsection .RM 3.17.4.7.4/, Interpreting Trace Output Formats. Because the trace memory is limited, the duration of the trace is inversely proportional to the amount of detail recorded. One way to get a long history of activity is to restrict the trace to store only the UIDs of the processes that run. This gives a good, long picture but little resolution. Transfer Trace An alternate method (which is the default) is to store the addresses involved in every nonsequential change in execution flow. That is, for every branch, jump, call, and return instruction, the address of the instruction (or from address) and the destination (or to address) are recorded. In addition, whenever a change in process occurs, the new process UID is recorded so the to and from address can be interpreted in context. This gives more detail than the UID-only option. Data History Trace The data history mode allows recording of the program data accesses. Each time a data access occurs, the trace memory records the data, the data address, a read/write flag, and the current program address. When an address range is specified on the INIT:UMEM input message, the block matcher is used and the trace only records data when a memory location within the range is accessed. By using a UID comparator, the trace can be limited to a unique process. Simultaneous Data History and Transfer Trace A simultaneous data history and transfer trace records all data associated with a data history trace and a transfer trace with the exception of a load or store flag indicating data accesses. The data history and transfer trace data are previously described. Each time a nonsequential program instruction is fetched, the UN615 DUC board receives a signal from the AT&T 3B20D computer. When an address range is specified on the INIT:UMEM input message, the block matcher is used and the trace only records data when a read instruction, a write instruction or a transfer occurs within the address range. Function Trace The function trace memory mode records software function changes. The AT&T 3B20D computer native instructions, SAVE and RETURN, are set up using OPCODE matchers and any other conditions established by the INIT:UMEM input message. When a SAVE instruction is executed, the CALL address (the previous program address), the SAVE address, and the current UID value are recorded. Execution of RETURN instruction allows trace memory to record the RETURN address (the current program address), the following program address, and the current UID value. When using an address range with function trace, the range specified must be matchable with a DUC address matcher. This is more restricted than UID, transfer, data history, or simultaneous data history and transfer traces (these traces use the block matcher and can therefore match on any specified address range). In order to use the address matcher for an address range, the starting and ending addresses must be of a form where the leftmost hex digits of both are equal, and the rightmost digits of the starting address are all ``0'' and the rightmost digits of the ending address are ``F '' (for example, 0x123000 - 0x123FFF or 0x10000 - 0x1FFFF). A function trace uses two triggers. Function With Parameters Trace The trace of functions with parameters records call instruction address, save instruction address, and parameters pushed on the stack. The stack address and stack size may be specified with the INIT:UMEM input message. If these values are not supplied, default values will be used. Unlike the function trace, return instructions will not be recorded. The ADDR key word may not be used with function and parameter traces to restrict the address range of function calls which are recorded. This is due to the difficulty in resolving which stack writes are due to function calls outside of an address range which would not be recorded. An address matcher is used to detect stack writes. If a stack address and stack size are specified, they must specify an address range as described in the previous section. For example, the default stack address is 0x6A0000 and stack size is 0x1000. This specifies an address range of 0x6A0000 through 0x6A0FFF. A function with parameters trace uses two triggers. Simultaneous Data History and Function With Parameter Trace The simultaneous trace of data and functions with parameters trace records data history trace information (with the exception of the read/write flag) and function with parameter trace information. The data history and function with parameters traces were described in previous paragraphs. As with the previous trace type, if a stack address and range are specified, they must describe a range that can be matched with an address matcher. In addition, if a data history address range is specified, it too must be of this form (for example, 0x2000 - 0x2FFF). This trace uses three triggers. UID Restriction A trace can be restricted to trace only while a particular process is running using the UID option. The UID specified on the input message is the pcode of the process to be traced. Any copy of the process with that pcode is traced; and since the UID recorded whenever the process changes includes the dct slot, multiple incarnations of a pfile can be distinguished. ADDR - Address Range Selection The ADDR keyword limits program tracing to the access of a specific word of memory or to a given range of addresses. When a trace uses the block matcher, any address range can be specified. This is the case for UID, transfer, data history, and simultaneous data history and transfer trace. The function trace uses an address matcher to implement the ADDR range. This is more restricted and is described in the function trace section. The ADDR keyword is not implemented for function with parameter traces. For simultaneous data history and function with parameter traces, the ADDR keyword uses an address matcher to specify the data history address range. Stop When Full Versus Circular The trace can be set up either to automatically stop tracing when the memory fills up or to trace indefinitely, always replacing the old data with the new. This pair of options is used to set up the various scenarios of tracing as described in the next section. The options are independent of the type of data stored. If the STOP FULL option is chosen, an output message is printed indicating that the trace stopped for that reason. Stop Trace on Condition The COND keyword may be specified along with any combination of E, M, and S to stop a running trace if one of the following conditions occurs: E: Stop the trace if an external event occurs. This is triggered by the external event backplane signal on the DUC board. S: Stop the trace if a hardware stop-and-switch occurs. M: Stop the trace if a hardware maintenance reset function occurs. The condition matcher uses another trigger for trace. The following paragraphs describe the most common trace scenarios. The trace input messages and associated output messages are shown in the Table .AW TT/. See the appropriate input or output message in AT&T 235-600-700 or AT&T 235-600-750, Input Messages Manual and Output Messages Manual, respectively, for details on any specific input message and for system responses. Before Trace To record the sequence of execution that precedes a known event, do the following: 1. Decide what type of trace to use. There are seven trace types: o UID Trace o Transfer Trace o Data History Trace o Simultaneous Data History and Transfer Trace o Function Trace o Function With Parameters Trace o Simultaneous Data History and Function With Parameter Trace. 2. Decide whether to restrict the trace to a particular UID or PID or to allow all processes to be traced. These decisions depend on the scope of the problem being debugged (system wide versus internal to a process) and the length of history needed. 3. Start the trace in the circular mode and define a breakpoint to trap the target event and stop the trace. When the breakpoint fires and the trace stops, the history leading up to the event will be in the trace memory. After Trace To see the sequence of execution that occurs after a target event, do the following: 1. Decide what type of trace to use. There are seven trace types: o UID Trace o Transfer Trace o Data History Trace o Simultaneous Data History and Transfer Trace o Function Trace o Function With Parameters Trace o Simultaneous Data History and Function With Parameter Trace. 2. Decide whether to restrict the trace to a particular UID or PID or to allow all processes to be traced. Another option is to restrict the trace to a particular PID. 3. Configure the trace to stop when trace memory is full. 4. Define a breakpoint to trap the target event and start the trace. Between Trace A trace can be set up to record data between two target events (up to the memory limit of the utility circuit installed). The breakpoint used to trap one target event starts the trace and another breakpoint defined for the other event stops the trace. To record this information, do the following: o Use the STOP FULL option on the INIT command to indicate whether any data gets lost because of the finite size of the trace memory. The data lost, if any, is the new data. If the new data is needed, repeat the trace in the CIRCULAR mode. In the circular mode, the old data is lost, preserving the new data. o Use the UID option to restrict the trace to those processes from a particular pfile or the PID option to restrict the trace to a particular process incarnation. o Because of utility circuit hardware restrictions, choose the two breakpoints carefully. o An execution breakpoint that starts the trace is implemented in software. UID and Transfer Output Formats The trace memory dumped by the OP:UMEM command is printed in order, oldest to newest, row by row. Every entry is one of three types as follows: o utility id marked with U, o from address marked with F, o or to address marked with T. The utility id entries are 24-bit hexadecimal numbers that are presented in the format shown as follows. The rightmost 12 bits (3 hexadecimal digits) are the process pcode. The leftmost 8 bits (2 hexadecimal digits) are the dct slot. The remaining hexadecimal digit is unused. 23 16 15 12 11 0 __________________________________ | | | | | | | | | | | | |__________|________|______________| dct slot unused pcode (8) (4) (12) Utility id Print Format A process identification (pid) consists of a dct slot or index (of which the higher order byte is always zero) and an incarnation count as shown as follows. 31 16 15 870 ___________________________________ | | | | | | | | | | | | |________________|________|_________| incarnation dct slot count (16) (16) Process id An easy correspondence can be made between the trace UID entries and the pids if the pids are expressed in hexadecimal. In kernel processes, the OP:STATUS:PROCESS, ALLKERNS; command prints out the dct slot directly; however, it is in decimal and must be converted. The address entries are all virtual addresses within the process indicated by the most recent preceding UID entry in the trace memory. Any from address is the address of a branch, jump, call, or return instruction that was executed. The following to address is the address to which control transferred. Occasionally two to addresses will be recorded adjacent to each other. This implies that the first to address itself caused a transfer of control (not an uncommon occurrence in compiler generated code). Between any to, from pair, the code was executed without branching. Note: Although the disassembler decodes the a1 OPCODE as a 4-byte return instruction, the microcode (and hence the trace output) treats it differently. The a1 is really a 2-byte no-op instruction. The actual return instruction is the 2-byte 7b instruction. As a result, the from address recorded for a return will be the address of the 7b -- 2 bytes beyond the return indicated in the disassembly listing. Typically with the UN21 utility circuit, several to and from addresses precede the first UID entry in a transfer trace. If it is important to know (but not obvious) what process they belong to, rerun the same trace scenario with the STORE UID option on the INIT:UMEM command. Working backwards from the end of the two dumps, UID entries can be matched to determine the UID of the early transfers in the first trace. Data History Trace Format The data history trace records the program address at which a specified address is being accessed, the data address, a read or write flag, and the data value. The format for this trace is displayed in the following example. DATA HISTORY TRACE PROGRAM DATA ADDRESS ADDRESS DATA 000076 3c0034 <- 00000004 00005e 3c0034 -> 00000004 00007c 3c0034 -> 00000004 000090 020068 <- 61000000 The leftmost column contains the program address accessing a specified memory address or address within a specified range of memory addresses. The center column contains the data address, and the rightmost column contains the data value. A read operation on the data address is indicated by a right arrow -> and a write operation by a left arrow <-. Function Trace Format The function trace records calls and returns, the address branched to, and the utility ID. A sample of the output is as follows. FUNCTION TRACE CALL OR SAVE OR RETURN ADD. RETURN-TO ADDR. UID 0000a8 call 000248 00000900c0 000272 call 000420 00000900c0 000260 reto 000276 00000900c0 000300 reto 0000ac 00000900c0 Output lines contain keywords, call or reto, in the second column to indicate a call or return. Calls and their respective returns are indented equal amounts to reflect nesting. For calls, the first column contains the address of the call instruction. The third column contains the save address branched to. For returns, the first column contains the address of the return instruction, and the third column lists the program address being branched to. The fourth column contains the utility ID for both calls and returns. Simultaneous Transfer Trace and Data History Format This trace records transfer trace and data history trace. A sample of the output is given as follows. SIMULTANEOUS TRANSFER AND DATA HISTORY TRACE PROG ADD DATA ADD DATA VALUE FROM-ADD goto TO-ADD UID 000026 020010 ? 61000000 00002e 020011 ? 00620000 . . . 00029a goto 00029c u=0x17d (282fa0) 000029e 6a0190 ? 000001a6 The indented output represents data history. The lines not indented represent program transfer trace data. The left column of the program trace is the from program address. The middle column is the to program address, and the right column is the uid of the to address. The data history's left column is the program address. The middle column is the data address, and the right column is the data. With the simultaneous transfer and data history trace, it is not possible to know whether the data history trace is a read or a write, thus a question mark is inserted in data history trace output. Function With Parameter Trace Format The function with parameter trace records function calls and full-word data write accesses on the process stack. A sample of the output follows. FUNCTION TRACE WITH PARAMETERS PASSED CALL ADD SAVE ADD PARAMETERS/AUTOMATICS 000120 0002d4 (0x00000019) 0001a0 000258 (0x0000000a,0x00000020, 0x00000000,0x00000002) 000280 0002a0 ?(0x0000000,0x00000002) The left column provides the program address of the call instruction. The next column contains the save instruction address. The remaining one or more columns enclosed within parentheses contain the parameter(s) pushed; where the last parameter pushed appears first in the list. The automatics from the previous function may also appear with the parameters. When it is unclear which parameters were pushed on the stack, a ``?'' precedes the left parenthesis. Simultaneous Data History and Function Trace Format This trace records the data history and function trace. A sample of the output is given as follows. SIMULTANEOUS DATA HISTORY AND FUNCTION TRACE FORMAT PROG ADD DATA ADD DATA VALUE (data history) CALL ADD SAVE ADD PARAMETERS/AUTOMATICS (function) 0000a4 0001d8 ?(0x00000005,0x00000045) 000d0 0001a8 ?(0x00000002,0x00000063) 000112 020038 ? 0x00000045 00011c 02003c ? 0x61000000 000126 020040 ? 0x00034567 The indented output is the function call with its parameters. Among these parameters, the automatics from the previous function may also appear. The left column is the call instruction address. The next column is the save instruction address. The next column is the parameter pushed, and the rightmost column is an automatic from the previous function. The unindented output is the data history for the data range specified. The left column is the program address. The middle column is the data address, and the right column is the data value. The left arrow, <-, means that the data was written. The right arrow, ->, means that the data was read. Table .AW TU/ lists information about the UNIX RTR operating system processes. RGRASP, a troubleshooting tool with an MML interface , is a single-user utility system for the Common Network Interface (CNI) ring nodes. The user interface is based on the GRASP tool found in the AM. However, several major differences exist, and the user should be familiar with RGRASP capabilities before using the tool. No new hardware is required for the RGRASP tool. Caution: Although RGRASP can be used by the craft, care should be exercised. Improper use of RGRASP can result in program mutilation or excessive utilization of system resources, both of which can lead to call processing down time. The current implementation consists of four processes; three in the AM and the fourth (monitor) in the DLN AP. The four processes are as follows: o RGP_KER: This is a UNIX system process kernel for the feature. It acts as the interface between the AM (RGP_CFT and RGP_PRT) and the ring node (monitor) processes. This process has to be killed-off in order to install the new version if it is updated via software update procedures. o RGP_CFT: This is a UNIX system process called to handle input messages from the craft shell. It parses and performs some preliminary checks on the input command and then relays it to the RGP_KER process for further processing. o RGP_PRT: This is a UNIX system process that handles printing of output. Message class SWM01 is used for the output. o Monitor: This is a system process that performs the actual operations required to handle breakpoints, memory dumping, and memory loading. It communicates with the RGP_KER process. RGRASP capabilities consist of the following: o READ memory in a ring node with the DUMP:RUTIL command. o WRITE memory in a ring node with the LOAD:RUTIL command. o Perform actions on breakpoints in ring node memory as follows: -- Set breakpoints in ring node memory with the WHEN:RUTIL command. -- Determine status of breakpoints with the OP:RUTIL and OP:RUTILFLAG commands. -- Temporarily disable breakpoints with the INH:RUTIL and INH:RUTILFLAG commands. -- Completely remove breakpoints with the CLR:RUTIL and CLR:RUTILFLAG commands. -- Enable/allow breakpoints with the ALW:RUTIL and ALW:RUTILFLAG commands. For detailed explanations, refer to AT&T 235-600-700, Input Messages Manual and AT&T 235-600-750, Output Messages Manual. Initial Setup Determine the address in memory that requires investigation by using the latest PR/PK listings provided. In other cases, these addresses may be provided by a field support organization. Determine which processor will be looked at (the DLN has an active and a standby processor). Use command OP:SLK or poke MCC Page 118 to determine this. Setting Breakpoints As a precaution, set breakpoints in only one processor at a time. Before setting a breakpoint in a program, the opcode code (OPC) must be known. Verify the OPC by using the DUMP:RUTIL command to dump the memory at the breakpoint address. If the expected OPC does not match the dump output, then the listings don't match the memory. At this point, don't go any further until the discrepancy is resolved. One possible explanation for the discrepancy is that the node software is out of date. To eliminate this possibility, remove and restore the target node (node to be breakpointed) to make sure that the newest version of the code has been pumped from the disk. Use the RMV:LN and RST:LN commands or MCC Page 118 pokes to achieve this. After the node has been pumped, try dumping the breakpoint address again. If it doesn't match up now, the listing is out of date. In this case, stop and get a current listing before proceeding. To set a breakpoint at address h'XXXXXX which has an opcode of h'YYYY, use the following command: < WHEN:RUTIL=32-2,AP,ADDR=h'XXXXXX,OPC=h'YYYY; After the command is entered, the user is prompted for the action list. It is best to use the most current WHEN:RUTIL manual page to see all the possible actions. A single breakpoint may execute up to 25 commands in its action list when hit. Only 25 action list commands are possible in any one processor. For example, if one breakpoint contained 15 action list commands, then only 10 more action list commands are available for other breakpoints in the same processor. The action list must be terminated by the WHEN:END command. As with GRASP, there need not be any commands in the action list except WHEN:END. It may be useful to know whether or not a piece of code was being executed. Initially all breakpoints are inhibited. Use the ALW:RUTIL command to allow all breakpoints in a given ring node or the ALW:RUTILFLAG to allow an individual breakpoint. Only five breakpoints can be set in any one ring node processor. Loading memory may drastically change program execution. If memory is not correctly loaded, it can interrupt or degrade service (for example, lose calls). The RGRASP tool has write permission to all parts of available memory. This makes the tool very powerful but also dangerous. Since OPC checking is not performed, it is possible to type in the wrong address and overwrite good data with bad data. If this should occur and the original contents cannot be loaded, the ring node should be removed and restored (pumped) to get back an original disk copy. Use the RMV:LN and RST:LN commands to remove and restore data. After a load, use the DUMP:RUTIL to verify the new contents in memory. Registers can only be loaded during breakpoint action lists. Dumping memory is a fairly straight forward and safe operation. All that is required is the address to dump. The current implementation allows 468 bytes of hexadecimal output to be dumped in one operation with the DUMP:RUTIL command. A user may dump memory either higher or lower than the starting address, or a range of addresses may be specified. Registers can only be read during breakpoint action lists. Ibrowse is an interactive tool that examines files containing a dump of UNIX RTR operating system physical memory. On the AT&T 3B20D computer, this file is usually /dev/pmem for the currently running processes, or /dev/ofln for the contents of the off-line memory. Locations in the address space of any process in memory can be displayed. Ibrowse also provides facilities for examining core dump files, as well as primitives to display ordinary unstructured files. These types of operation allow the use of Ibrowse as an on-line debugging aid as well as a static debugger. To execute Ibrowse, enter the command: ibrowse [file] File should contain the contents of physical memory. Following is a listing of Ibrowse commands: buf Turns on internal memory management (default). db file Examines the contents of file. null n Sets value for termination of indirect formats (initially 0). pn n Treats subsequent addresses from the perspective of process n. pn k Switches to kernel's address space. pn p Uses physical addressing - no virtual address translation is performed. This mode is also used for examining unstructured files. pn c Treats currently attached file as a core dump file. pn Displays current process. sup Switches to supervisor address space. sym pfile Uses the symbols from pfile to allow symbolic addressing. user Switches to user address space. vtop n Converts virtual address to physical. The db command informs Ibrowse of the file containing the physical memory spectrum. For example, db /dev/pmem causes Ibrowse to reference the physical memory driver for subsequent requests. Entering this command is equivalent to invoking ibrowse with the name of the physical memory file as its argument. The db command without an argument causes Ibrowse to name the current physical memory file. After a physical memory file is specified, Ibrowse can then display virtual addresses. Initially, these addresses are interpreted within the kernel's address space. A command for changing to the address space of any process in memory is described as follows. Display commands in Ibrowse are of the form: addr/format Address can be a number, arithmetic expression, search string, or variable name enclosed in quotes (for example, ``buffer''+30 is a legal address). If the `` / '' in a display command is replaced by `` = '', Ibrowse evaluates an arbitrary arithmetic expression to determine an address. The address is then printed, rather than its contents. This allows Ibrowse to be used as a calculator. The command: ([3+5]/[2*1])*8=X displays the result of the calculation in hexadecimal (0x20). A format consists of a concatenation of the following symbols: a Name of variable at address. b Byte. c Character. 'd, d, D Decimal of 1, 2, and 4 bytes, respectively. 'o. o. O Octal of 1, 2, and 4 bytes, respectively. s Null terminated string. 'u, u, U Unsigned decimal of 1, 2, and 4 bytes, respectively. 'x, x, X Hexadecimal of 1, 2, and 4 bytes, respectively. In addition, any format descriptor preceded by a number causes that descriptor to be used the specified number of times. For example, transfer vectors are stored at virtual address 0x760000 in the kernel. The command: 0x760000/10X displays the first ten entries in this segment as long hexadecimal numbers. Segment descriptor entries (SDE) reside at address 0x1a000 in the kernel. The command: 0x1a0000/XX'd'ddddd'd'dXXX displays the fields of the first sde structure in this segment. Internally, Ibrowse supports three concepts useful in displaying structured data: o A current address o A next address o A current format. After a display command, the current address (available as ``.'' in address calculations) is set to the first address displayed (0x1a0000 in the example). The next address is set to the first address following the last item displayed (0x1a0020). The current format is set to the format used in the display. Successive carriage returns after a display cause Ibrowse to use the current format to display the information starting at the next address. Therefore, similar structures stored in consecutive memory locations are easily displayed. The formats commonly used to display data from memory have been described previously. For each format, Ibrowse prints one value for each format entry using a tab separator. Additional format components that allow a more structured display are shown in Table .AW TV/. Ibrowse initially interprets addresses as references to the kernel's address space. The command: pn N references the address space of process N for successive displays. The command: pn k returns to kernel space, while: pn reminds the user of the current address space. Ibrowse also directly addresses physical memory. The command: pn p enters physical addressing. All UNIX system processes run at the supervision level, and the sup and user commands are excluded. To peruse core dump files with Ibrowse, enter the command: pn c This command treats the currently attached file as a formatted core dump. The data, text, stack, etc., of the late process may then be accessed with virtual addresses as though the process were still in memory. A virtual address may be converted to the physical address by entering the command: vtop N This returns the physical address corresponding to the virtual address N. Ibrowse searches forward or backward for a particular sequence of values in the current address space. The search pattern consists of two parts: a format and a sequence of values. Ibrowse uses each format letter to determine the size of the corresponding value in the value list. For example, when the following pattern is specified: /2X2x 1 2 3 4/ Ibrowse scans forward in the current address space searching for a sequence of 12 bytes containing a long 1, long 2, short 3, and short 4, respectively. The same sequence enclosed in question marks causes Ibrowse to search backwards for the sequence. (Note that the values still appear in ascending memory locations.) When in virtual addressing mode, Ibrowse limits its searches to the current segment. Therefore, if the current address is x760008, a forward search examines locations x760008 to x780000 first, followed by locations x760000 to x760008. In physical addressing, the entire range of the physical memory file is examined. The command: sym [pfile] reads the symbol table of the pfile. Functions and external variables maybe subsequently referenced by name. The symbol section of the pfile must be swabbed correctly; otherwise, Ibrowse will report ``symbol not found''. For example, consider checking the file manager's tasks. The information needed, located in the tasktab array, consists of four word entries. The following commands display the first eight entries in the table: pn 4 /* enter fmgr's address space */ sym /bootfiles/fmprc /* attach to current file manager. */ * (it may be necessary to run * 3bswab to examine the symbols * on the 3b) */ ``tasktab''/8(4X=) /* quoted string causes symbol lookup */ To find the virtual address of the i-node table, enter: ``i-nodes''=X Occasionally, it is useful to convert a virtual address into a symbolic name (for example, looking up a program address). Ibrowse provides a special format (a) for this translation. If, for example, the address of the i-nodes previous array was x1000, the command: x1010=a prints the string ``i-nodes+16'' (the offset is always decimal). To avoid excessive reads of the current file, Ibrowse maintains a cache of recently accessed memory areas. To adjust the size of pages used for this memory management (initially 512 bytes), use the command: framesize n To disable buffering completely, use the command: nobuf The nobuf command is useful when examining volatile locations on a running machine. To restore buffering to its initial 512-byte frame size, use the command: buf Ibrowse overwrites contiguous memory locations with a set of values. At present, however, the physical memory driver (/dev/pmem) does not support writing, so the feature may be unusable on a running AT&T 3B20D computer. If the driver is changed to allow writes, or if there is reason to modify an off-line dump, patching is straightforward. The core file must be reattached with permission to patch by entering the command: dbp [file] Modifications then take the form: addr#``format value1 value2 ...'' The supplied values are written in memory beginning at the addressed location. As with searches, the format determines the size of each supplied value. As a result, 3X is equivalent to 3D or DXD, etc.; each value in the value list determines its own radix. For example, to replace three transfer vectors beginning at location 760010 with 120, 130 and 140, the patch command is: x760010#``3X 120 130 140'' When a line begins with an exclamation point (!), Ibrowse invokes the shell for the remainder of the line. The q command terminates Ibrowse. Ibrowse stores some formats as macros. Macro names are drawn from the set of capital letters unused by Ibrowse (Ibrowse uses D, I, U, O, and X at present). A macro is defined by entering the letter, a space, and the desired format string. Entering the letter alone gives the current definition of the macro (if any). The following examples clarify both the use of macros and the additional format facilities. Example 1 The command: P 5(4X=) defines a macro P which prints 20 hexadecimal longs, four to a line. Each line is preceded by the address of the first word on the line. (The ``='' issues a newline, then prints the address.) The macro P is then used in formats in the same way as any predefined letter. The command: x76000/2P prints the first forty transfer vectors. Example 2 Macros can be recursive. A recursive macro is useful when used in conjunction with the indirect addressing capability of the curly braces. If a program has a binary tree consisting of the following structures: struct btree { char title[40] ; struct btree *left ; struct btree *right ; } the macro: B 40c{B}{B} effects a preorder traversal of the tree. An in-order traversal of the same tree is accomplished with the [mark] and [skip] feature: B [40]{B}[ka][-44]s['a]{B} This macro skips the character string, displays the left subtree, marks where it is (ready to print the right subtree), jumps back to the start of the title, displays it as a string, and finally jumps back and displays the right subtree. Note: Use the null command note to set the termination criteria for an empty child if it is other than the default zero. Example 3 On the AT&T 3B20D computer, a stack entry has the following format: struct stack { int args[NARGS]; /* arguments to function - variable number. */ int ret_addr; /* return address. */ int *oargp; /* old argument pointer */ int *ofp ; /* old frame pointer - points to caller's local * data. */ int save[10] /* 10 words of save information */ int locals[NLOC] /* local variables for function. */ } Given the address of the top (that is, most recent) stack entry's local variables, a macro to format a stack trace is defined as: S [-52]=a{XX}{S} This macro skips back to the parent's return address, prints the current location and the function's name (=a), prints the first two arguments ({XX}), and recurses ({S}). The current program address is not on the stack and must be obtained from the save state in the processes' pcb. Example 4 The structure: struct xyzzy { long good ; char dull [2000] ; long better ; } can be viewed with the macro: Z "good "D<2000c>"better "D The resulting output lines have the following form: good (goodva11) better (betterva11) good (goodva12) better (betterva12) . . . . . . . . . . . . Ibrowse redirects I/O to or from a file. The command: > [file] directs subsequent output to the named file. If file is not specified, stdout is used. Redirection is terminated by an interrupt or a line containing only a ``>''. The command: >> file appends to an existing file. The command: < [file] takes a set of commands from the specified file (or stdin if no file is specified). The <[file] command is useful when reading in a file of predefined macros. File can be replaced with a shell escape to allow redirection to or from a command. For example, > !fgrep ffffffff 0/50(4X=) > /* terminate redirection */ locates the -1's in the first 400 words. The idump is a tool which allows a user to dump parts of common object format files for interactive examination of their contents. It can be used for: o A.out files (the output of the AT&T 3B20D linkage editor, 3bld) o Pfiles and shared libraries (the output of the AT&T 3B20D linkage edit process, 3bldp) o Minimal files (the output of file extraction, fextract) o Update files (the output of overwrite generator, ogen) o Simple object files (the output of the AT&T 3B20D C- language compiler, 3bcc). Idump also permits the examination of multiple object files by specifying on the command line either a list of files or an archive that contains object file members. Under the Bourne shell, idump is invoked by entering the command: idump [file...] Table .AW TW/ provides a listing of the idump commands and their output. An example of the use of the idump m command is as follows: m g -- Open the next object file in argument list and dump the file header. If the m is used alone, explanations for all the commands available in idump are listed. The idump returns an exit code of zero. If an interrupt signal is received, idump returns to its command mode. Note: Normally, idump is used in the interactive mode. Idump should NOT be executed through the craft shell except as described as follows. Idump may be executed via the craft shell by using the EXC:ENVIR:UPROC command. Special steps must be taken with UNIX system commands, however, to make interactive communications with the user possible. One method that can be used to execute an interactive command, such as idump, via the craft shell is shown in the following example: <INPUT> EXC:ENVIR:UPROC,FN="/bin/sh",ARGS("-c","/usr/bin/idump /bin/date<<!<lf> t main<lf> q<lf> !")<CR> PF <OUTPUT> < M EXC ENVIR UPROC /tmp/dumper COMPLETED CURRENT FILE: /bin/date Sat Sep 8 02:27:49 1984 F_AR32W F_LSYMS F_LNNO F_EXEC F_RELFLG Magic Nscns Time/Date Symptr Nsyms Opthdr Flags 00550 17 0x1ba016f5 0x00002800 549 0x0fec 0x020f : Symndx Name Value Scnum Type Sclass Numaux [ 16] main 0x00000048 1 ()INT EXT 1 s/u/e tag=0 fcn size=0x788 lptr=0x0 endx=22 tv=0 : In the previous example, the Bourne shell (UNIX operating system shell) is called to execute by the EXC:ENVIR:UPROC,FN="/bin/sh" portion of the command line. The argument list follows the command name and is of the general format, ARGS("arg1","arg2",..."argN")!. In the example, the first argument, "-c", is an argument to the UNIX operating system shell (/bin/sh) program. This argument instructs the UNIX operating system shell to interpret the next argument as if it were a string of characters from a terminal. The effect is a UNIX operating system terminal that executes a single command line. The EXC:ENVIR command limits the line to a maximum of 63 characters. The second argument, which begins with "usr/bin/idump and terminates several lines later with !"), constitutes the string being passed by the UNIX operating system shell program. Typically, the idump program reads commands from the terminal in an interactive mode with the user. Noninteractive UNIX system commands to be processed by idump can be made interactive by passing them in the second argument string in the form of a here document. As the name implies, the here document commands are read from ``here'' rather than the terminal. Some characteristics of a here document are as follows: o A here document begins with the sequence, <<!, and terminates with the next occurrence of ! at the start of a line. The use of ! is arbitrary; any character can be substituted in its place. o Each line within the here document represents a command; in this case to idump. o Each line within the here document is terminated with a <lf> (line feed) rather than a <cr> (carriage return). o A <cr> is a statement terminator which indicates the end of an input message to the craft shell. In the previous input/output example, the symbol table entry for symbol main of process "/bin/date" was specified in the EXC:ENVIR command line as "t main". Sometimes it is convenient to place command strings into files called scripts, and then execute the script. Following are three examples which show the creation of executable scripts: Example 1: <INPUT> EXC:ENVIR:UPROC,FN="/bin/sh",ARGS("-c","/bin/echo '/usr/bin/idump<<! \\\\n\\$2 \\$3\\\\nq\\\\n'>>/tmp/dumper")! PF <OUTPUT> < M EXC ENVIR UPROC /bin/sh COMPLETED Example 1 illustrates the use of ``/bin/echo'' to create a file, /tmp/dumper, via the craft shell. In this example, the ``/bin/sh'' program is passed a string in argument 2 by the use of the ``-c'' argument. Argument 2 contains the following: a. The command, /bin/echo, used to echo its output into a file named /tmp/dumper. The entire string inside the single quotes, ', is redirected into tmp dumper. b. The symbol, >>, directs the output into a file, in this case /tmp/dumper. The use of the double > appends the output to any existing text in /tmp/dumper. A single > overwrites any existing contents in /tmp/dumper. c. A single backslash, \\, hides the meaning of special characters from the UNIX operating system shell. Example 2: <INPUT> DUMP:FILE:ALL=FN="/tmp/dumper" PF <OUTPUT> < M 09 DUMP FILE ALL COMPLETED /usr/bin/idump $1<<! $2 $3 q ! Example 2 illustrates the use of the DUMP:FILE command to examine the contents of the newly created file, /tmp/dumper. Dumper contains the pathname to the idump command followed by $1 and the beginning of a here document. Run time arguments to be passed from the command line to idump are represented by $1, $2, and $3. The name of the file to be acted upon will be contained in $1. Arguments to idump will be contained in $2 and $3. Example 3: <INPUT> <ALW:FILESYS:ACCESS=700,FN="/tmp/dumper" PF <OUTPUT> < M ALW FILESYS ACCESS COMPLETED Example 3 illustrates the use of ALW:FILESYS:ACCESS to make "/tmp/dumper" executable. Note: Caution should be exercised in writing and using scripts. Only persons thoroughly familiar with shell programming should write scripts. Also, scripts should not be executed out of crontab unless approved by a high-level support. The script created in the dumper execution command (see the following) can be executed using EXC:ENVIR. In this case, arguments are passed to /tmp/dumper in the argument list of the EXC:ENVIR message as follows: a. ``/bin/date'' will be substituted for $1 in ``/tmp/dumper''. b. ``t'' will be substituted for $2 in ``/tmp/dumper''. c. ``main'' will be substituted for $3 in ``/tmp/dumper''. Therefore, /user/bin/idump is passed the command, ``/t main'', inside the here document of ``/tmp/dumper''. The result is, idump outputs the symbol table entry for function, main. An example of script execution as described previously is as follows: <DUMPER EXECUTION> EXC:ENVIR:UPROC=FN="/tmp/dumper",ARGS("/bin/date","t","main")! PF < <DUMPER OUTPUT> M EXC ENVIR UPROC /tmp/dumper COMPLETED CURRENT FILE: /bin/date Sat Sep 8 02:27:49 1984 F_AR32W F_LSYMS F_LNNO F_EXEC F_RELFLG Magic Nscns Time/Date Symptr Nsyms Opthdr Flags 00550 17 0x1ba016f5 0x00002800 549 0x0fec 0x020f : Symndx Name Value Scnum Type Sclass Numaux [ 16] main 0x00000048 1 ()INT EXT 1 s/u/e tag=0 fcn size=0x788 lptr=0x0 endx=22 tv=0 : The UPedcud is an interactive, menu-driven tool which allows a user to read, edit, or alter the contents of the CUD and History files maintained in the 5ESS switch by the Program Update subsystem. From the contents of the CUD entry, a user can verify what type of change was applied to which file for a particular BWM. The status of that particular BWM can be determined from the contents of the history file. Warning: This tool overwrites data in system files. Incorrect use of this command will result in the removal of needed information. If a change to either the CUD or History File is necessary, it should be made to a copy of the file; not to the original. Changes should not be made to original files without the concurrence of the AT&T Customer Technical Support (CTS) Organization. Before using the UPedcud tool, make sure that Program Update commands are not executing. The UPedcud will affect Program Update and could cause a disruption of service. Changes which have been agreed to by the CTS Organization and entered are made to a buffered copy of the CUD or History file. They are not made in the permanent copy until the w command has been entered to update that level of the editor. UPedcud offers ten major menus and a number of submenus. The major menus are as follows: o Password o Program Update File Editor o CUD Header Editor o CUD Item Display o CUD Item Editor o History File Main Menu o History Header Item Editor o History File Item Editor o Dependent Files -- History Header Item Editor o Dependent Files -- History File Item Editor. UPedcud menus and submenus are presented to the user on a scrolling screen display. A given menu page is always displayed in its entirety. The UPedcud menu structure is shown in Figure .AW G87/. The number of greater than symbols shown near the left top of the display for a particular menu or submenu indicates the level at which that item resides in the editor. For example, the CUD Item Display is in the first level and shows > [see Figure .AW G97/ (Example 1)]. The CUD Item Editor menu and submenus are in the second level and show >> (see Figures .AW G98/ and .AW G99/). Third and fourth levels are indicated on the screens in the same manner. Level three is the History File menu page from which level four options can be selected (see Figure .AW G102/). As each major menu item is quit, the user is returned to the next higher level in the editor until the Program Update File Editor is reached. Quitting the Program Update File Editor returns the user to the Bourne shell. A user password is required for access to the UPedcud program. The password requirement serves as an additional check to prevent accidental modification of files. Passwords may be obtained from the CTS Organization. When the command /no5text/prc/UPedcud is entered at the Bourne shell prompt, the password menu will appear as shown in Figure .AW G88/. When the password has been successfully entered, the Program Update File Editor menu is displayed showing the two types of data that can be accessed: 1. CUD header 2. CUD item. Figure .AW G89/ shows an example of the Program Update File Editor display. Option number 1 from the Program Update File Editor menu calls up the CUD Header Editor menu which displays some of the information stored in the CUD file header. This information is as follows: 1. The number of CUD entries 2. The pointer to the end of CUD 3. The number of the last system update recorded in CUD 4. The number of the last BWM header sequence recorded in CUD 5 - 16. The number of temporary overwrites (Temps) to the SM, CMP, MSHG, and SM peripherals. The number of Temps for each is shown for standard, loaded, and basic configurations. 17 - 22. The pump map used during SM or CMP pump. (The SM pump map includes peripheral targets.) The SM or CMP pump map is shown for standard, loaded, and basic configurations. The CUD Header Editor menu allows a user to edit or view information stored in the CUD file header as follows: o Edit package sequence numbers stored in CUD header (option s) o Edit names of the last three official BWMs which are permitted to be backed out. These names are used by the back out last official 3 deep (BOLO3) feature (option l) o View system patch addresses (option a) o Edit the BWM table (option t) o View CUD and History record sizes (option d). If the BWM package is backed out, the number of CUD entries is reduced by the number of temps backed out. The last update number is not reduced. If the BWM package is reapplied, the number of CUD entries starts at the reduced number and the last update number from its current value. Option t is used to edit the BWM table of 20 slots which is created in the CUD header to store the information of the first 20 BWMs contained in the CUD file. The BWM table is created to avoid the sequential search of the CUD file for a particular BWM. When the CUD Header Editor menu is quit, the user is returned to the Program Update File Editor menu. An example of the CUD Header Editor menu that is displayed when the user selects option number 1 from the Program Update File Editor menu is shown in Figure .AW G90/. Each entry in the BWM table contains the name of a BWM and the file offset to the beginning of its last CUD entry. Figure .AW G91/ is an example of the screen display which shows this information. The BWM names (in chronological order) are shown the first column of each entry. The second column is the file offset to the beginning of the BWMs last CUD entry. This information is critical and should not be changed. Option d displays the sizes of various records in CUD and History files. This is a display only option, and changes cannot be made. Figure .AW G92/ is an example of the information displayed when option d is entered. The package sequence numbers for current BWMs can be displayed and edited by selecting option s from the CUD Header Editor menu. Each sequence number on the display corresponds to a loadable package. The name of the loadable package referenced by each sequence number will be displayed at the prompt line as the sequence number is selected. In Figure .AW G93/, the name of the 27th loadable package, ``GLISDNEDLS'', is displayed in the line prompting for a new sequence number. The number of loadable packages changes from one software release to another. An example of the package sequence numbers display is shown in Figure .AW G93/. To support the BOLO3 feature, names of the last three official BWMs can be displayed and edited by selecting option 1 from the CUD Header Editor Menu. An example is shown in Figure .AW G94/. Option a from the CUD Header Editor displays pumpable peripheral OSsyspatch addresses. Each address number in the submenu corresponds to an image. The submenu includes all the SM, CMP, and peripheral (pumpable or nonpumpable) targets. Figure .AW G95/ is an example of the OSsyspatch address display for the 5E6 and 5E7 software releases. Following is a list of address numbers and corresponding images for the 5E6 and 5E7 software releases: Address No. Peripheral Image 1 ISLU (Integrated services line unit) 2 PH2A (128-channel protocol handler with ACCESS image) 3 LDSU (Local digital service unit) 4 RAF Recorded announcement function) 5 ISTF Integrated services test function) 6 PH2G (128-channel protocol handler with GATEWY image) 7 ODMA (Operational direct memory access) 8 PH3C (Common image 128 channel protocol handler) 9 OIOP (Operational input/output processor) 10 PI (Protocol interpreter) 11 HDSU (DSU2 diagnostic image) 12 DDMA (PH2 Direct Memory Access Processor diagnostic image) 13 Standard SM 14 Loaded SM 15 Basic SM 16 CMP AP 17 CMP MSGH Figure .AW G96/ is an example of the OSsyspatch address display for 5E8 and later software releases. Following is a list of address numbers and corresponding images for 5E8 and later software releases: Address No. Peripheral Image 1 ISLU (Integrated services line unit) 2 IDCU CCP (Integrated Digital Carrier Unit Common Control Processor) 3 IDCU LSI (Integrated Digital Carrier Unit Loop Side Interface) 4 IDCU DLP (Integrated Digital Carrier Unit Data Link Processor) 5 LDSU (Local digital service unit) 6 RAF Recorded announcement function) 7 ISTF Integrated services test function) 8 PH2A (128-channel protocol handler with ACCESS image) 9 PH2G (128-channel protocol handler with GATEWY image) 10 ODMA (Operational direct memory access) 11 PH3C (Common image 128 channel protocol handler) 12 OIOP (Operational input/output processor) 13 PI (Protocol interpreter) 14 HDSU (DSU2 diagnostic image) 15 DDMA (PH2 Direct Memory Access Processor diagnostic image) 16 Standard SM 17 Loaded SM 18 Basic SM 19 CMP AP 20 CMP MSGH Option number 2 from the Program Update File Editor menu calls up the CUD Item Display menu. The CUD Item Display main menu shows a listing of up to 10 CUD entry summaries. If a CUD contains more than 10 entry summaries, initially the last 10 will be displayed. Regardless of which CUD entry summaries are included in the window of displayed items, they will always be numbered 1 through 10 on the display. The number of the CUD item starting the list and the total number of CUD items are identified on the screen above the listing. Figure .AW G97/ (Example 1) shows the CUD Item Display menu. Notice that 10 CUD entry summaries are listed, starting with #18 (and going through number 27). In the display, however, they appear as numbers 1 through 10. Unless the first or last CUD item appears in the listing of items being displayed, the user can move the window either forward or backward to examine other entries. If the first item is displayed, the window can only be moved forward (f is the only move option). Vice versa, if the last item is displayed, the window can only be moved backward (b is the only move option). In Figure .AW G97/ (Example 1), 10 CUD items are listed starting with #18. Since, the last CUD item (number 27) is included in the listing, b is shown as the only move option. Accordingly, the screen shows that b has been entered to move the window backward. Figure .AW G97/ (Example 2) shows the screen display with the window moved backward 10 entries (the default quantity). The listing now starts with CUD item #8 (and goes through number 17). Since neither the first or last CUD item is included in this display listing, the user can move the window either forward or backward (f or b are move options). A user wanting to get from the display shown in Figure .AW G97/ (Example 2) to one that includes CUD item number 26 would enter f to move the window forward and press return to default the forward movement to 10 entries. A screen display would then appear with summary data for Cud items #18 through 27 as shown in Figure .AW G97/ (Example 3). The CUD Item Display will show all SM configurations as changed regardless of whether or not the particular image is used in the office. In addition to offering forward and backward movement options, the CUD Item Display main menu allows the user to either quit and return to the Program Update File Editor menu or go down another level in the editor for more detailed examination of specific CUD items. The next level down from the CUD Item Display menu is the CUD Item Editor menu. From the CUD Item Display menu, a user can access additional information about a specific CUD item by entering the screen number of the item at the system prompt, <Enter option or Cud entry number to examine:. For example, in the screen display shown in Figure .AW G97/ (Example 3), the user has entered 9 (to examine CUD item 26). When 9 is entered, the Cud Item Editor menu displays a numeric listing of data fields with detailed information about CUD item #9. An example of the CUD Item Editor menu screen display for CUD item #1 is shown in Figure .AW G98/. In the CUD Item Editor menu, all data fields for a particular CUD item are displayed in a readable format, including English descriptions for the status bits. The user can modify the data in any field by entering the number for that field at the system prompt, >>Enter option or field number to modify:. Note: It is strongly advised that NO changes be made to a CUD item without the concurrence of the CTS Organization. When a field number has been entered for modification, a submenu for that field, if there is one, is presented; otherwise, it is a toggle. From the submenu, the user can change the value of the field and return to the CUD Item Editor menu. If no change is desired, pressing the return key will return the user to the CUD Item Editor menu by default without changes being made. If it is a toggle, the user can select the number and its value will be changed. Figure .AW G99/ is the submenu shown when field number 2, Update type:, is selected for modification in 5E6 and 5E7. Figure .AW G100/ is the submenu shown when field number 2, Update type:, is selected for modification in 5E8 and later. The affected SM list submenu is accessed by selecting option s Show affected SM(s) from CUD Item 1 menu. An example of the affected SM list is shown in Figure .AW G101/. One level down from the CUD Item Editor Menu is the History File Main Menu which offers four options as shown in Figure .AW G102/. The History File Main Menu allows a user to access the history file header (choice #1), the history file item (choice #2), the dependent file's history file header (choice #3), and the dependent file's history file item (choice #4). Menu displays of choices #3 and #4 are identical to displays of choices #1 and #2, respectively. The difference is that choices #1 and #2 edit the history file while choices #3 and #4 use the dependent file's history file as input. To edit the history header information, the user would select 1, Edit history file header information from the History File Main Menu. If the dependent file's history file is targeted, 3, Edit dependent file history file header information, should be selected instead. Figure .AW G103/ shows an example of the History Header Editor Menu when 1 is selected. If 3 is selected, the only difference in the display is the first line in the screen which would read ``Cud Item #1 Dependent File History File Header''. A submenu of file update type, as shown in Figure .AW G104/, is displayed when the user enters 7 at the prompt >>>>Enter option or History header field number to modify. In the History File Item Editor Menu the fields of a CUD item's associated history file are displayed in a readable form. A 1-line summary of the CUD item is included at the top of the menu. English descriptions are given for the transaction types and the status flags. To select a history file for examination, from the CUD Item Editor Menu enter h, Show history files, followed by 2 from the History File Main Menu. An example of the History File menu that will be displayed is shown in Figure .AW G105/. Note that if the CUD item specifies both a history file and a dependency file, only a history file can be displayed. Dependency file examination is described in Section .RM 3.17.8.2.8/. Note: Although the History File Item Editor menu is actually four levels down in the editor, screen displays of this menu indicate 3 levels down (see Figure .AW G105/). The user may modify any of the fields by inputting the appropriate field number at the system prompt, >>>Enter option or History field number to modify:. Note: Changes should not be made to history files without the concurrence of the CTS Organization. Figure .AW G106/ is the display for field 6, Transaction type:. The transaction type must not be changed. To do so will cause the Program Update subsystem to be (or not be) expecting certain temporary files associated with this BWM. Figure .AW G107/ is the display for field 7, Status flags:. These status flags indicate the current status of the BWM associated with this history file. Figure .AW G108/ is an example the Function Names and Addresses screen that is displayed when option f is entered. Generic utilities are resident, real-time software debugging tools which support a set of commands to aid maintenance personnel with the verification, localization, and temporary correction of application programs running in some 5ESS switch processors such as the CMP, CMPMSG, FPC, IDCU, IDCULSI, ISLUCC, MMP, PH2/1, PH3, PI, PPC, and SM. Caution: The improper application of generic utility programs can be service affecting. Before implementing any of the generic utility functions, consult local supervision concerning policy. It is recommended that the implementation of any generic utility program be discussed with the Electronic Switching Assistance Center (ESAC) prior to starting the procedure. The 5ESS switch generic utilities allow a user to do the following: o To dynamically display the target processor's memory as hexadecimal output or in a disassembled format. o To temporarily overwrite the target processor's memory. o To copy data from one memory location to another location in the target processor's memory. o To combine a series of UT input commands into a single command clause. o To perform comparisons of data and alter UT command selection based on the comparison. This is the IF and ELSE commands which can also be nested. o To do limited conversions of a function name or global symbol to an address or location for symbolic debugging. o To temporarily store data and constants through the use of utility variables. o To call or execute a function in the target processor and pass up to 20 bytes of data as parameters. o To change the operational flow of a program by performing a GOTO operation. o To routinely perform a user defined set of UT commands on a TIMED basis. o To perform a user defined set of UT commands at specific user defined points in the target processor's operational text. o To utilize the scripting capability to create a file on the UNIX operating system using the MCC terminal. Not all of the features and capabilities listed are maintained by UT for all of the supported processors. The UT input and output manual pages must be used to determine which commands, options, and software releases are supported for each processor. The implementation of generic utilities commands is controlled by the following: o The input of UT commands by maintenance personnel via the MCC or a corresponding terminal. o The firing of UT breakpoints which have been set by maintenance personnel. o The sequencing of a UT TIMED WHEN clause that has been scheduled by maintenance personnel to run after some time delay. o The initiation of fault recovery operations in the switch which can inhibit or remove UT WHEN commands. All UT output data or error messages are printed on the ROP and displayed on the originating video terminal. All generic utility input commands are entered manually by maintenance personnel at the MCC or a corresponding terminal. The commands are input as either an immediate command, immediate clause, or a WHEN command clause. Following is a description of each type: o An immediate command is any single UT input command (except the WHEN command) which is entered by the user. Upon entry, the command is validated for errors. If no errors are found, the command is executed, an output message is printed at the ROP and calling TTY, and the command is removed from the target processor. If an error is found, the same process is followed except the command is not executed. It should also be noted that real-time breaks may occur and are acceptable during the execution of an immediate command. o An immediate clause is any group of UT input commands (except WHEN commands) which are entered by the user. The operation of the immediate clause is the same as an immediate command except each operation is performed on the entire clause. This means that upon entry, the entire clause must pass validation to be executed, and each command will then be executed. If any single command of the clause does not pass validation, the entire clause will not be executed and a single error message is printed on the ROP and calling TTY. It should also be noted that real-time breaks may occur and are acceptable during the execution of an immediate clause. o A WHEN command clause is a single WHEN command or any group of commands that start with a WHEN command. The operation of a WHEN command clause is different from either an immediate command or immediate clause because the command, or entire clause, is stored in the target processor's memory for later execution, provided no errors are found in the validation phase. If a WHEN command clause passes validation, it is stored in an inhibited state. This means a second command must be used to enable the clause. Following are definitions of the two types of WHEN command clauses which can be formed: 1. A WHEN breakpoint clause sets up a software interrupt in the target processor which allows UT to execute the given sequence of commands at specific points in the application code. It should be noted that real-time breaks are not acceptable during the execution of a breakpoint clause. 2. A timed WHEN clause sets up a cyclical timer in the target processor which allows UT to execute the given sequence of commands on a scheduled basis. It should be noted that real-time breaks may occur and are acceptable during the execution of a timed WHEN clause. In order to use the generic utility commands, an understanding of how the commands are formatted in the input manual pages is required. Table .AW TX/ can be referenced to determine the conventions, definitions, and symbols used for formatting input commands. Generic utility (UT) commands consist of an action verb, identification field(s), and optional data field(s). Several commands which are executed sequentially can be strung together. All commands, which are part of a string of commands, except the last one must be terminated with a ``!''. The last command should be the END command and must terminate with ``;'' (MML format). All UT input commands are very similar in format. The basic UT input command format is action verb:UT:processor ID,optional parameters,message terminator. Following is an example of the DUMP:UT:CMP input message syntax format which is similar to that used in all of the UT input manual pages: DUMP:UT:CMP=0,{MATE|PRIM}[,DIS][,EA][,L=a], {ADDR=b|REG=c|REGS|UVAR=d|GVAR="e"} [,INDIR=f][,OFF=g[-g][-g]]{!|;} A breakdown of the format syntax in this example is as follows: o DUMP is the action verb which indicates the action requested by the user and to be performed by UT. o UT is always present in generic utility input commands. It serves as one of the identifiers of the input message. o CMP=0 identifies the processor where the operation is to take place. This identifier can be used with other qualifiers to further describe which physical unit is the target of the operation (for example, MATE, PRIM). o MATE or PRIM is a required parameter for this UT input message. The user must use one of these qualifiers. The field converts a logical processor into a physical location. This field is not always used in all UT messages; but when it is there, it must be filled in. o DIS, EA, L, INDIR, and OFF are optional parameters used in this UT input message. These fields allow the user to further define the type of information retrieved, the format of the output, or the starting location of the operation. The optional fields are always defaulted to a value, and not all optional parameters can be used at one time. o ADDR, GVAR, REG, REGS, and UVAR are addressig field identifiers used to determine where the information is going to or coming from. The addressing field is required in almost all of the UT input messages, but the identifiers used will vary from message to message. o The ``!'' or ``;'' is used to end each UT input command. One of these symbols is required for each message. The ``!'' terminates the input message and also indicates that the message is part of an on-going clause. The ``;'' indicates that this is the absolute end of the message or clause. Based on this format, an example of a valid input command could be as follows: DUMP:UT:CMP=0,PRIM,GVAR="INsynch",EA; This example would print in hexadecimal the effective starting address of the global symbol INsynch (in this case a function) from the active or primary CMP to the ROP and calling TTY. There are many more combinations of commands which can be created, all of which have their own uses and abilities. Some of the options, however, are only valid when used in combination with other commands. Refer to AT&T 235-600-700, Input Messages Manual, Volume 1, User Guidelines section, for additional information on command format. The generic utilities consist of 13 commands (action verbs) which are separated into 5 functional categories as follows: 1. Data Transfer Commands include the following: o DUMP o LOAD o COPY. 2. Conditional Commands include the following: o IF o ELSE o ENDIF. 3. The When Command is as follows: o WHEN. 4. When Controlling Commands include the following: o ALW (allow) o INH (inhibit) o OP (operational status) o CLR (clear) o END. 5. Execute Command is as follows: o EXC (execute). Data transfer commands allow the user to move, print, and write data to addressable system locations. Data transfer commands are described as follows: Dump Command The DUMP command is used to print the contents of one or more sequential memory locations, microprocessor registers, or utility variables in the specified processor. The dumping of the microprocessor registers (due to the dynamic nature of these registers) can only be performed inside UT breakpoint clauses. The length of dumps is always provided in bytes, but the maximum dump length will change for each of the different processors supported. The output is printed in hexadecimal (the default case) but can be printed in a disassembled (string) format. There are two basic differences in the gathering of data which need to be noted. They are as follows: 1. When a dump is performed outside a breakpoint clause, real-time breaks are taken after each message is formatted. This means the dumping of data (which does not fit in one message) is not a snap shot of the memory to be dumped but a gathering of the requested data over a period of time. This is acceptable for dumping information which is not real dynamic such as the operational text of a function. 2. When a dump is performed inside a breakpoint clause, real-time breaks are not taken. This means that the dumping of requested data is a true snapshot. However, the amount of data dumped in a breakpoint is limited to less than 2000 bytes. The processing of a breakpoint causes UT to store all output messages for that clause in an output buffer (2000 byte) which is then printed out as a deferred operation. All messages formatted are placed here; not just the data being dumped. Therefore, the real length limit must include the overhead of each message when included in a breakpoint clause. This approach is very useful when dumping dynamic data or data which is only accessible during breakpoint clauses. Load Command The LOAD command allows the user to overwrite memory in increments of long word, word, or byte sizes. The user specifies the start address (where the load shall begin) and the size of the values (1 to 4 bytes per value) to be loaded. The maximum total length per command (in bytes) is dependent on the target processor. The length (L) divided by the SIZE of each value provides the number of values expected. However, it is illegal to have a remainder. As part of the overwrite operation, most of the target processor's write protection is removed. Thus, the user is allowed to overwrite almost anything in memory. There are obvious exceptions however, such as read-only memory (ROM) which is addressable, but physically cannot be written. A load complete message is printed for each successful operation, unless the load is part of a WHEN command clause. Copy Command The COPY command is used to transfer data from one internal processor location (that is, absolute address, register, variable, utility variable, or symbolic address) to another, move constants to an internal location, and to increment, decrement, or multiply the value. The COPY command consists of three sets of parameters of which the third set is optional. In the first set, the user specifies the destination address. The second set, or second and third sets, allow the user to supply the value to be transferred or give a description of where to find the values. The COPY command is in fact an assignment statement in the form of (A = B [(+|-|*)C], where A, B, and C are the three sets of parameters. The user invokes the ``PLUS'' option by typing PLUS on the command line. This causes the data from the third parameter to be added to data from the second parameter. Likewise, the ``MINUS'' option is invoked by typing MINUS on the command line, but data from the third parameter is subtracted from the second parameter. The ``MULTIPLY'' option is invoked by typing MULTIPLY on the command line, but data from the third field is multiplied by the second field. The parameters can be a combination of absolute addresses, registers of the microprocessor, utility variables (UVAR), symbolic addresses, or constants. Following are two different forms of operation which need to be noted: 1. When a COPY command is performed outside a breakpoint clause, options which deal with the microprocessor registers are not allowed. A copy completed message is printed for each successful operation. 2. When a COPY command is performed inside a breakpoint clause, all available operations are valid, but no copy completed message is printed. The COPY command is limited to four bytes of data copied per command. During the overwrite operations, most of the write protections are removed. Thus, the user can transfer data to almost anywhere. This command then allows for the transfer of data based on dynamic addresses. Conditional commands allow the user to make comparisons of data of up to four bytes per test and optionally execute a list of UT commands if the comparison is true. The conditional commands also provide the ability to execute a separate list of UT commands if the comparison is false. The basic form of the conditionals is as follows: if the tested condition is true, perform the following user defined list of UT commands, else perform a secondary list of user defined UT commands. Conditional commands can also be nested, which allows the user to have several conditions evaluated before executing the list of UT commands. The conditional commands are described as follows: IF Command The IF command allows the user to set up a comparison of two values. Both values are user defined and can be constants, data, addresses, registers, and more. The comparison is also user defined and can be one of the following types; equal to, greater than, greater than equal to, less than, or less than equal to. The IF command does not print any messages, but it allows a list of UT input commands to be performed when the condition is tested and is found to be true. It should be noted that the comparison is made with sign-extended logic, and not all command options are allowed outside a breakpoint clause (basically the microprocessor registers). ELSE Command The ELSE command allows the user to establish an alternate list of UT commands to be executed whenever the comparison performed in the associated IF command is found to be false. This command is only used in conjunction with the IF command. ENDIF Command The ENDIF command allows the user to continue entering utility commands that are not associated with the IF or ELSE condition of a command clause. Nesting of IF, ELSE, and ENDIF commands is allowed, and the only limit to the amount of nesting is the maximum of 45 commands total in any single processor. The nesting of the conditional commands can be shown by the following: if (A > B) then if (A < C) dump data (X) else (A >= C) dump data (Y) copy data (A to address P) endif else copy data (1 plus counter to address counter) endif The WHEN command gives a user the ability to sequence through a defined list of UT commands at a given point in the application code or at an approximate time interval. The generic utilities provide for two types of WHEN commands; WHEN BREAKPOINT and TIMED WHEN which are defined as follows: WHEN Breakpoint Command WHEN breakpoint clauses allow maintenance personnel to interrupt the application code of a process in the target processor, execute a predefined sequence of UT commands, and resume execution of the process with minimal effect to the real time of the process. A WHEN command can be placed at any memory location in random access memory (RAM), but it must be placed at the start of any executable instruction for it to work. For memory protection, the value at the desired address in RAM is compared with what the user provides as the value of the OPCODE. If the comparison is false, the WHEN command will be removed and an error message is printed. After a valid WHEN clause is entered by maintenance personnel, it is stored in memory in an inhibited state. While the clause is in the inhibited state, the breakpoint (trap instruction) has not been placed in memory at the specified location, and none of the commands of the clause can be executed. Maintenance personnel must use the ALW command to enable the breakpoint. The ALW command places the trap instruction in the specified memory location and marks the state of the WHEN command to active. This means that any time the microprocessor executes the trap instruction located at this address, the following events occur: 1. Microprocessor registers are saved by the operating system. This allows UT to access the data contained in these registers at the time the exception occurred. After UT has processed the breakpoint, the registers are used to return the operational flow of the code back to the original point of the trap instruction. 2. Maskable interrupts are blocked during the processing of the UT WHEN clause. 3. Generic utilities determines which breakpoint has been hit and sequences through the list of UT commands contained in the WHEN clause. 4. Output messages formatted by this sequence of UT commands are placed in an output buffer maintained by the UT process. The buffer is currently limited in size (2000 bytes), so care must be taken to prevent an overflow of information. This buffer cannot be unloaded when UT is processing a breakpoint. The placement of the breakpoint determines what data is available and how to access it. The OPCODE, which is replaced by the breakpoint, is not executed until the WHEN breakpoint clause has been performed. Thus, if data is dumped from a location defined by a dynamic pointer, the breakpoint cannot be placed at the address of the instruction which sets up the pointer. Timed WHEN Command Timed WHEN clauses allow maintenance personnel to execute a predefined sequence of UT commands at a user defined interval of time. Timed WHEN commands operate with a cyclical timer at the processor's normal level of operation and do not operate at interrupt level. After a WHEN clause is entered by maintenance personnel, it is stored in memory in an inhibited state. While the clause is in the inhibited state, the cyclical timer has not been established, and none of the commands of the clause can be executed. Maintenance personnel must use the ALW command to enable the timed WHEN. The ALW command sets up a cyclical timer with the operating system for the specified length of time and marks the state of the WHEN command to active. This means that when the time interval is reached, a message is sent to the UT process indicating a timed WHEN needs to be processed. Generic utilities determine which timed WHEN has fired and sequences through the list of UT commands contained in the WHEN clause. As part of timed WHEN processing, the UT code does not have access to the microprocessor registers, and dumped data is taken over a period of time (not a snapshot of the data). Once a WHEN breakpoint command or a timed WHEN command is allowed, it remains active until one of the following events occurs: a. The WHEN clause has been executed the number of times the user specified (refer to the HIT option described in this section under Command Parameters). b. The user clears or inhibits the WHEN clause (refer to the CLR and INH commands described in this section under WHEN Controlling Commands). c. The generic utilities audit has removed the breakpoint because an error has occurred in the storage of the WHEN command clause. d. Pumping of the particular SM, CMP, or PH3 containing the WHEN removes all WHEN commands in the processor. e. As part of a selective initialization or a single process purge of generic utilities, all timed WHEN commands in the processor are inhibited. The craft needs to allow the timed WHEN commands to use them again. f. As part of a full initialization, all timed WHEN commands are cleared from the processor. If these timed WHENs are needed, the craft must reenter the command clause. g. For 5E6 and later, if a CMP soft switch occurs, UT follows these rules: o All breakpoints in the old active CMP are moved to the new active CMP and maintained in their current state. o All breakpoints in the old standby CMP will be removed and not moved to the new standby CMP. If these breakpoints are needed, the craft must reenter the command clause. h. As part of a selective initialization of a CMP, UT performs an inhibit operation on any active WHEN command in the processor. The craft needs to allow the breakpoints to use them again. i. As part of a full initialization of a CMP, UT performs a clear operation on any WHEN command in the processor. If these breakpoints are needed, the craft must reenter the command clause. j. For 5E7 and later, as part of a selective initialization of an SM or a PH3, UT performs an inhibit operation on any active WHEN command in the processor. The craft needs to allow the breakpoints to use them again. k. For 5E7 and later, as part of a full initialization of an SM or a PH3, UT performs a clear operation on any WHEN command in the processor. If these breakpoints are needed, the craft must reenter the command clause. The WHEN controlling commands enable the user to allow/enable, inhibit, clear/remove, and view the operational status of one or more WHEN commands in the target processors. These commands may be entered within a WHEN clause to manipulate other WHEN clauses. The WHEN controlling commands are allow (ALW), clear (CLR), inhibit (INH), operational status (OP), and END and are described as follows: ALW Command The ALW command enables a single WHEN clause or all WHEN clauses that are in the inhibited state in the target processors. Following are two basic types of operations which can be performed: 1. When the ALW command enables a WHEN breakpoint command, a trap instruction is placed at the address defined in the WHEN command. Checks are performed to make sure the OPCODE expected at the given address matches what is truly in memory. If the check does not pass, an error message is printed and the WHEN command will be removed by the UT audit. If the trap is placed in memory, whenever the trap instruction is hit by the microprocessor, the list of commands associated with the WHEN command will be executed. 2. When the ALW command enables a TIMED WHEN command, a cyclical timer is started. Whenever the timer expires, a message to perform the list of commands associated with the WHEN command is sent to the UT process. A TIMED WHEN cannot be allowed inside a WHEN breakpoint clause due to operating system constraints. CLR Command The CLR command removes a single WHEN clause or all WHEN clauses from the target processors regardless of their current state. Following are two basic operations which can be performed: 1. When the CLR command removes a WHEN breakpoint command, the WHEN cannot be reenabled; it must be typed in again by the user. If the WHEN command was inhibited at the time of the clear operation, the WHEN is only removed from UT's knowledge. If the WHEN command was active, the correct OPCODE is placed back into the operational code at the address defined in the WHEN command, and then UT's knowledge of the WHEN is removed. 2. When the CLR command removes a TIMED WHEN command, the WHEN cannot be reenabled; it must be typed in again by the user. If the WHEN command was inhibited at the time of the clear operation, the WHEN is only removed from UT's knowledge. If the WHEN command was active, the cyclical timer is retired and then UT's knowledge of the WHEN is removed. INH Command The INH command disables a single WHEN clause or all WHEN clauses that are in the active state in the target processors. Following are two basic operations which can be performed: 1. When the INH command disables a WHEN breakpoint command, the correct OPCODE is placed back into the operational code at the address defined in the WHEN command. The WHEN command clause, however, is left in the UT memory and can be reenabled with another ALW command. The WHEN breakpoint command is then effectively ignored at this point. 2. When the INH command disables a TIMED WHEN command, the cyclical timer is deleted. The WHEN command clause, however, is left in the UT memory and can be reenabled with another ALW command. A TIMED WHEN command cannot be inhibited inside of a WHEN breakpoint clause due to operating system constraints. OP Command The OP command causes an output list of the status (inhibited or active) of a single WHEN clause or all WHEN clauses contained in the target processor's memory. The output lists the status, WHEN identification, hit count, and some detailed information of the WHEN such as the defined address of the WHEN. END Command The END command is used to signify the end of a utility request. The END command is only used as the last command of a clause and must terminate with a ``;''. However, the user may terminate any clause with any other UT input command, but the terminator must be a ``;''. The execute command is EXC and is described as follows: EXC Command There are two different forms of the EXC command which can be used in the supported processors. The two forms are identified by the indicators CALL and GOTO and are described as follows: 1. The EXC command which performs the CALL option allows the user to enter a function name to make a function call while passing up to 20 bytes of data. The user is responsible for determining the correct parameters and the order in which to pass them. The returned data of the function is printed and saved. It should be noted that the execute command can handle a function returning any type of data (for example, the function returns a short, pointer to a structure, long, etc.). A check is performed to make sure the function being called is truly a function. 2. The EXC command which performs the GOTO option allows for an immediate jump of the microprocessor to a user defined absolute address. This command is only valid inside a WHEN breakpoint clause. The processor identification (ID) refers to the particular 5ESS switch processor on which program analyses are being performed. Following (in alphabetical order) is a listing of possible processor IDs and the processor associated with each. PROCESSOR ID PROCESSOR CMP Communication Module Processor CMPMSG Communication Module Processor Message Handler FPC Foundation Peripheral Controller IDCU Integrated Digital Carrier Unit IDCULSI Integrated Digital Carrier Unit Loop Side Interface ISLUCC Integrated Service Line Unit Common Controller MMP Module Message Processor PH2/1 Packet Switch Unit Protocol Handler (Model 1 & 2) PH3 Packet Switch Unit Protocol Handler (Model 3) PI Peripheral Interface PPC Pump Peripheral Controller SM Switching Module Some generic utility commands are used to analyze programs in all 5ESS switch processors, while others are used with only a few. Table .AW TY/ shows the 13 UT commands, the processors which support each command, and the software release with which the support became effective. The UT command parameters, which include optional data fields and the required addressing modes, vary depending upon the command (action verb) being used and the processor being analyzed. Following is a listing of UT command parameters and a description of each: 2 PARAMETER DESCRIPTION ADDR: This specifies a physical address at which the action is to take place. The starting address can be modified in some commands by using indirections and offsets. ARG: This specifies the number of arguments or parameters to be passed as 2-byte numbers to a function. CALL: This identifier indicates the function, whose name is specified by the symbol contained in FUNC, will be called by the UT process in the specified processor. A check is performed to make sure the symbol is a function. DIS: This causes the data to be dumped in a disassembled format instead of straight hexadecimal output. The disassembly of the data is performed based on the type of microprocessor used in the target processor. Two different forms of disassembly can be produced. The first is based on the MOTOROLA(R) 680XX instruction set, and the second is based on the INTEL(R) 80X86 microprocessor. This option causes the processor to route the raw memory data to one of the disassemblers which are located in the AM. The AM receives raw data from the processor, disassembles it, stores the output in an AM buffer, and then prints it at the ROP and the calling TTY. EA: This indicates that the data to be used (that is, dumped, copied, or compared) is the determined effective starting address of the operation instead of the contents of the address. EQ: This is a key word identifier which indicates equal to. It is used in the COPY command to separate the source and destination parameters. Data identified to the right of ``EQ'' is transferred to the location identified at the left of ``EQ''. In the IF command, ``EQ'' is the type of condition to be performed. FOREVER: This indicates that the WHEN command, once it has been allowed, will not be removed by the UT process based on the number of times it has been utilized. When this option is used, the WHEN command is only removed or inhibited by fault recovery actions or another manual UT input WHEN controlling command. FUNC: This indicates that the function is specified symbolically (for example, FUNC = "function name"). Must be entered as a string of up to 15 characters enclosed in double quotes. GE: This is a key word identifier which indicates the condition to be evaluated is greater than or equal to. GOTO: This identifier indicates that a C-statement GOTO will be performed. This option is only allowed in conjunction with a WHEN breakpoint, and the jump will be from the address of the breakpoint to the address defined by the ADDR field of the EXC command. GT: This is a key word identifier which indicates the condition to be evaluated is greater than. GVAR: This is the global variable which indicates that the address is specified symbolically (for example, GVAR = "function name"). Must be entered as a string of up to 15 characters enclosed in double quotes. HIT: This is the hit option which accepts a number as an input parameter. This number is used by UT in the target processor to indicate the number of times a WHEN command can be utilized before it is automatically inhibited by the UT process. The primary use of this option is to provide a method which prevents UT from using too much of a processor's real time which can cause fault recovery actions to take place. INDIR: This is the indirection option which accepts a number as an input parameter. This number is used by UT to indicate the number of levels of indirection. The definition of a level of indirection is to take the contents of an address and use the contents as a pointer. Thus, one level of indirection means UT will go to the address defined by the contents of the address of the main level. If more than one level of indirection is indicated, the second level will be determined based on the first level (that is, a pointer points to a pointer). IO: This key word accepts a number as an input parameter. The number indicates the particular input/output port to be used in the operation. An 8-bit length is imposed on any operation performed on an IO port. L: This option specifies the length (in bytes) of the action to be taken. LE: This is a key word identifier which indicates the condition to be evaluated is less than or equal to. LT: This is a key word identifier which indicates the condition to be evaluated is less than. MATE: This is a key word which causes the action to occur only to the standby processor. In fully duplex units (such as the SM), the operation is actually performed on the active unit by doing reads/writes across the update bus. In units which are duplex but do not have an update bus (such as the CMP), the entire action is performed on the standby unit. MINUS: This is one of the optional keywords used in the COPY command. This indicator causes the data defined in the source field of the command to be subtracted by the data defined in the optional third field of the command before the copy of data is performed. MULTIPLY: This is one of the optional keywords used in the COPY command. This indicator causes the data defined in the source field of the command to be multiplied by the optional third field of the command before the copy of data is performed. MSK: This is the mask option which accepts a number as an input parameter. This number specifies the value to be ``anded'' with the final result before evaluating the conditional statement. NE: This is a key word identifier which indicates the condition to be evaluated is not equal to. NOPRINT: This keyword causes the suppression of two messages which would normally be printed every time an active WHEN command was processed by UT. The messages are the WHEN STARTED and WHEN COMPLETED messages. However, commands contained in the WHEN command clause may still print messages (for example, the DUMP command). The use of this option reduces ROP messages and speeds up the processing of WHEN command clauses. OFF: This is the offset option which accepts a number as an input parameter. This number specifies the number of bytes to be added to the address contained in the message before determining the final starting address for the action. For the WHEN command, offsets are added to the address of a function (determined symbolically) to determine the final address of the breakpoint (this is a description of relative offsets). In any other UT command, an offset is illegal unless an indirection is indicated. The offset in these commands is added to the data found at each level of indirection. OPC: This is the OPCODE option which accepts a number as an input parameter. This number is expected to be a match to the OPCODE instruction found in the target processor's memory at the given address. The OPCODE must be a 2-byte value. If this parameter does not provide a match, the WHEN command will not be accepted by UT in the target processor. PARM: This is the parameter option used to supply the data needed by a function which is being called by the user. All parameters must be 2 bytes each. If more than one parameter is to be entered, they should be entered as a list separated by dashes (maximum of 10 values). If the parameters are long words or addresses, two adjacent values are combined by UT. The order of the 2 bytes combined will change with the type of processor (see AT&T 235-600-700, Input Messages Manual, for details). If a function needing parameters is called, but insufficient or no parameters are provided, the parameters will be taken from the stack UT is currently running on. PLUS: This is one of the optional keywords used in the COPY command. This indicator causes the data defined in the optional third field of the command to be added to the source field of the command before the copy of data is performed. PRIM: This is a key word which causes the action to occur only to the active processor. This key word is used by UT to indicate the CMP which is logically active. Output messages printed will indicate which physical CMP is active. REG: This key word accepts the symbol of a single MC680XX microprocessor as an input parameter. The symbol identifies which register is to be acted upon. A set of dummy registers is used for the operation if the command is not part of a WHEN breakpoint clause. REGS: This key word specifies that the contents of all the MC680XX microprocessor registers be dumped. A set of dummy registers is used for the operation if the command is not part of a WHEN breakpoint clause. SIZE: This key word accepts a number as an input parameter. This number is used to define the size of each value (number of bytes) to be written into the target processor's memory. The size of each value (long word, word, or byte) must be constant for the message. TIME: This key word accepts a number as an input parameter. The number is in milliseconds and defines the time interval between successive executions of this timed WHEN clause. UTIL: This key word indicates that the operation is to be performed on all WHEN command clauses in the specified processor. UTILFLAG: This key word accepts a number as an input parameter. The number is a unique label which identifies a WHEN command in the specified processor. Checks are performed to make sure the label is unique. UVAR: This key word accepts a number as an input parameter. The number is an index (starting at zero) of an array of longs in the specified processor's memory. This memory is owned by UT and can be used by maintenance personnel as a temporary storage location. VAL: This is the value option used to provide the data or constant to be used in the operation. If more than one value is to be entered, they should be entered as a list separated by dashes. The number of values allowed in the list varies from message to message. Refer to AT&T 235-600-700, Input Messages Manual, for details on specific input messages and AT&T 235-600-750, Output Messages Manual, for system responses. The scripting capability allows the user to create a file on the UNIX operating system using the MCC terminal. The file, created in advance consisting of WHEN-clause sequences, would be executed at a later time from the MCC terminal. The following is a typical scripting scenario. a. The user creates a file (a series of UNIX operating system commands) similar to the following: IN: FILESYS: DIR, DN "/tmp/script"; IN: FILE: APND, FN "/tmp/script", LINE 1! "/cft/bin/pdshl "WHEN:UT: SM=1, ADDR=X'51008, OPC=h' 321A, UTILFLAG=0 ; IN: FILE: APND, FN "/tmp/script", LINE 2! "/cft/bin/pdshl "ALW:UT: SM=1,UTILFLAG=0 ; IN: FILE: APND, FN "/tmp/script", LINE 3! "/cft/bin/pdshl "INH:UT: SM=1, UTILFLAG=0 ; IN: FILE: APND, FN "/tmp/script", LINE 4! "/cft/bin/pdshl "OP:UT: SM=1, UTILFLAG=0 ; b. The file is enabled by typing the following command: ALW:FILESYS:ACCESS "755", FN "/tmp/script"; c. The user can now execute the file from the MCC terminal by typing the following command: EXC:ENVIR:UPROC, FN "/tmp/script"; where ``tmp'' represents the complete path to the file, and ``script'' is the filename. The EXC command executes the file which, in turn, executes the input commands in the file. d. The following command removes the file: CLR:FILESYS:FILE, FN "/tmp/script"; There are also commands to delete, replace, and append lines to a file. For additional information, refer to AT&T 235-600-700, Input Messages Manual. In the 5ESS switch, hardware and software errors generate reports or messages. These reports come in several forms [for example, audits, asserts, or processor recovery messages (PRM)] and generally provide information about what has happened. The reports, with the exception of PRMS, may be printed at the ROP, collected in a log file, or both. The PRMs may only be printed at the ROP. The message class of the report determines its handling or disposition. The purpose of the log files is to reduce the number of messages being printed at the ROP and still maintain gathered information. The log files can be used for: o Detecting and correcting transient errors before they cause system outages. For example, AM correctable memory errors can occur at an increasing rate over many days. This problem can be detected by studying the log file entries and making corrections to errors before they occur at a rate high enough to cause automatic recovery actions. Note: Transient errors are usually not detected by diagnostics because of their transient nature. However, sufficient information exists in the log file entry to determine the cause. o Determining the sequence of events that led to an initialization or maintenance interrupt. Each event in a log file has time-of-day information and sequence numbers. A study of this data can help determine possible machine problems. For example, if multiple errors caused an excessive error rate and triggered an initialization, the sequence numbers indicate the order of occurrence and the time stamp can verify that the occurrence was sufficiently short to cause the initialization. Entries from several log files may have to be pieced together to give a chronological order of events. Recreating the order of events is most easily accomplished by examining printouts of all the appropriate log files. There are two basic forms of log files in the 5ESS switch: UNIX RTR system log files and log files for the rest of the switch. A number of UNIX RTR system log files (for example, CONFLOG, MEMLOG, and PMLOG) contain specific types of messages. The MEMLOG file, which is the memory history file for the AM, contains supplementary data for memory error interrupts. The log files for the rest of the switch may or may not contain specific material. For example, log files such as RCLOG and ECDLOG contain specific information, but this is not true of the DAYLOG file. The DAYLOG file contains information from all of the SMs and attached peripherals (for example, PSUPH), the CMP (added in 5E6), and most of the application error reports from the AM (for example, application audit failures). The log files are defined in the classdef and device forms in the ECD. All log files in 5E6 and later software releases are contained in the directory, /log/log. Any entry made in a log file is an indication of trouble. Often a report will be printed on the ROP indicating the problem. However, maintenance personnel would have to look in the DAYLOG file for a detailed reason for the report. For example, a defensive check failure will print on the ROP, but associated stack traces, stack frames, and register dumps would be stored in the DAYLOG file. Log files are constrained by size limitations. The size of log files is handled in one of two ways depending on the type of file: 1. UNIX RTR system log files are limited in size to prevent system overflow. When a log file is first created, the file is called XXXXX1, where XXXXX stands for the log name. When half of the disk space is used, the contents of XXXXX1 are copied into XXXXX0. The most recent information is again stored in XXXXX1. When all the disk space is used, the ``1-part'' is again copied into the ``0-part'' overwriting the oldest data. This process will continue indefinitely. 2. In 5E6 and later software releases, the DAYLOG file will be handled like a UNIX RTR system file. This means that the most recent information is contained in DAYLOG1, and older information is contained in DAYLOG0. To help maintenance personnel determine if minor problems exist in the switch, a set of messages can be used to operate on the log files. Following is a basic list of functionalities provided and the commands to use for each: 1. View the entire log file or its specific parts: Commands give a user the ability to view a file on the basis of time (starting time and ending time are used), view certain message classes, or view reports coming from a particular unit (for example, SM=3). Combinations of options can also be requested. The OP:LOG command can be used in all software releases for the UNIX RTR system log files and for the DAYLOG log file in 5E6 and later software releases. The correct syntax and detailed information about command parameters can be found in AT&T 235-600-700, Input Messages Manual. Care should be taken when printing these files on the ROP because some files can hold over 1800 reports. When this many reports are being printed, messages for the current time frame may not be seen for some time. 2. Determine routing status of message classes: The routing status of message classes can be determined by using the OP:LPS:MSGCLS command. This command outputs the current log/print status of all or specific message classes. It can also be used to determine where all message classes are being sent [as can poke command 902 on MCC Display Page 110]. See AT&T 235-600-700, Input Messages Manual, for detailed information about this command. 3. Change routing status of message classes: The routing status of message classes can be changed by using the CHG:LPS command. This command permits a user to define where the reports will be sent [for example, logged, printed, both logged and printed, or neither (in which case the message is discarded in the generating module)]. The routing status can be changed on all messages or on specific message classes. 4. Use OP:STATUS:DATA,LISTDIR command to obtain information: The command OP:STATUS:DATA,LISTDIR can be used to obtain a list of files in a directory, their current sizes, and other information. The list of files produced may include some with the name rmfxxxx, where xxxx is any number. These files are generated when the AM is not sane enough to write to the log files. After these files are examined, they should be removed by using the CLR:FILESYS:FILE command. Refer to AT&T 235-600-700, Input Messages Manual, for detailed information on syntax, parameters, and format for both the OP:STATUS:DATA and CLR:FILESYS:FILE commands. A core dump takes place if certain faults occur or if a termination message requests one. Core dumps are images of the run-time state of processes that have been placed on disk in the /cdmp directory (or in a user defined directory specified by the termination message). Generally, a core dump implies an abnormal process termination. A core dump should be investigated to determine the cause of termination. Each site should save the core dump files when log files are saved, or as often as necessary. Core dump files must be removed periodically to allow enough space for future core dumps. Note: Files in the cdmp directory may not be useful to the office personnel. However, these files should be saved (just as log files and ROP output are saved) for forwarding to the technical assistance organization, if necessary. Diagnostic maintenance programs are integrated into the 5ESS switch hardware and software to provide self-diagnosis and trouble-locating capabilities for hardware faults. The diagnostics programs are controlled by the maintenance fault recovery, maintenance personnel, and routine exercises. Once the diagnostic has been initiated the unit will be removed from service and tested. When fault indications are found and the correct input message options are used, information will be printed which identifies the board or circuit that needs replacing. This is known as the trouble location procedure (TLP). The TLP provides a fast method for determining the cause of a hardware fault and therefore, its correction. After the trouble has been repaired, the unit can then be restored. This is done automatically by autonomous recovery actions or manually by maintenance personnel. To better understand the actions of diagnostics in the system, some of the following sections are separated into diagnostics in the UNIX RTR operating system area, and diagnostics in the CM and SM. Diagnostics can be invoked from three separate sources; maintenance fault recovery (FR), craft requests, and routine exercises (REX). The FR requests are made when operational errors are detected and identified in a particular hardware unit. These are called automatic (AUTO) requests. Craft requests via input messages on the MCC generate manual (MAN) requests. REX generates both AUTO and MAN diagnostic requests. The OSS REX Scheduler program generates AUTO requests, while a REX request by craft generates a MAN diagnostic request. The type of request (AUTO, MAN, or REX) determines a particular set of diagnostic test phases to be run. Each hardware unit type has a unique set of test phases and execution options dependent on request type. Information on specific hardware units is contained in AT&T 235-105-220, Corrective Maintenance Procedures. The automatic diagnostics process schedules diagnostic and restorals of units not brought up at boot (initialization) time and when units are removed through fault recovery actions. When the diagnostic is run as part of a fault recovery action, one of two basic actions occurs. o The unit passes the diagnostic testing and is restored to service. This is indicated by some form of a restore completed message, although these messages will have various forms for the different units. o The unit fails the diagnostic testing and is not restored to service. As part of this failure, information will be printed on the ROP indicating the failing phase and the hardware that is most probably bad. This automatically provides maintenance personnel with the information needed to recover from a hardware failure without having to perform the diagnostics manually. As indicated previously, the output messages which provide this information will have various forms for the different units. The diagnostics which are run automatically utilize the same commands that craft personnel would use for manually diagnosing the units. The commands use enough of the diagnostic options to provide the needed information without the craft having to run it manually, such as the TLP option. All of these options will be discussed in the Manual Diagnostics section of this document (following) and in greater detail in the appropriate pages of AT&T 235-600-700, Input Messages Manual. Manual diagnostics provides the maintenance personnel the ability to force specific options of diagnostic commands or control diagnostics when automatic recovery actions are inhibited. These commands will be split into two categories: AM diagnostic commands and the rest of the system diagnostic commands. The basic form of the diagnostic input message is as follows: DGN:unit=a,subunit=b; For input/output processor (IOP) and disk file controller (DFC) diagnostics where no subunit is specified, the basic input messages are as follows: DGN:IOP=a:<optional key words> or DGN:DFC=a:<optional key words>. (Optional key words are defined in AT&T 235-600-700, Input Messages Manual, and under the following full command format example). When each of these commands is entered, the named unit and all units under it in the diagnostic hierarchy will be tested. Table .AW TZ/ shows the diagnostic hierarchy. The subunit designation is optional and is used only when a specific subunit of the CU (control unit) is being diagnosed. In addition to the basic diagnostic input message, eight optional parameters may be specified. The full command format is: DGN:unit=a[,subunit=b][:[RPT=c][,RAW][,UCL] [,REX|,DEX]][,[PH=d[&&e]][,CONT][,TLP][,f]]; Descriptions of the optional fields are as follows: o RPT= (Repeat). Indicates the diagnostic should be repeated c times. The maximum is 256. Note: The RPT option does not override early terminations. The UCL should also be specified if the diagnostic terminates. o RAW= Indicates the diagnostic results of every phase should be printed. If all tests pass, this fact is printed. If any failures occur, data from up to 100 failing tests is printed. If you do not use the RAW option, only the first five failures per phase are printed. o UCL= (Unconditional). Indicates the diagnostic should be unconditionally executed with no early terminations. The basic diagnostic contains many early termination points. If one of these points is reached and previous tests have failed, the diagnostic does not continue. This may occur for two reasons: o Data obtained from the previous tests is sufficient to uncover the problem. o If previous tests have failed, going further may be dangerous. Caution: The UCL option should not be specified unless absolutely necessary since there is a risk of the diagnostic structure or the operating system crashing. o REX= (Routine exercise). Requests that automatic and routine exercise phases within the specified range be run. If no range is specified, all automatic and routine exercise phases are run. o DEX= (Demand exercise). Requests that automatic, routine, and demand exercise phases within the specified range be run. If no range is specified, all automatic, routine, and demand exercise phases are run. Variable d specifies the phase or range of phases. o PH= (Phase). Requests either a particular phase or a range of phases (in the form first-last). This may be a subset of the automatic phases and/or a demand phase or phases. Using the PH option is the only way that demand phases can be run. See AT&T 235-105-220, Corrective Maintenance Procedures, for the complete list of phases (that is, routine demand phases and supplementary demand phases for IOP, CU, and DFC). o CONT= (Controller). Specifies that subunits under the requested unit (and subunit) are not to be diagnosed. Due to limitations in the DFC and IOP drivers, the CONT option is the default for DFC and IOP diagnostic (DGN) requests. The CONT option is also available for the direct memory access (DMA) subunit of the CU. o TLP= (Trouble location process). Generates a circuit pack list if failures are detected by the diagnostic. Note: The UCL and TLP options should not be specified together because a TLP output of reduced accuracy can be produced. Within the diagnostic system, demand phase selection allows pinpointing problems or potential problem areas. Demand phases are optional and test specific units and subunits within the diagnostic hierarchy. The following guidelines may be helpful in understanding the demand diagnostics: o A phase is marked as demand because it takes a long time to run, requires manual intervention, or should not be run automatically. The demand phase, when requested, tests part of the unit specified. o Diagnostic demand phases are grouped in the same hierarchy as other diagnostics (CU, DFC, and IOP). o Demand phases are normally requested when standard routine diagnostics do not locate the problem area or can be requested as part of a preventive maintenance plan. o Some phases take up to 40 minutes to complete. o Some demand diagnostics require special procedures (refer to AT&T 235-105-220, Corrective Maintenance Procedures). This demand diagnostic phase needs some special attention. When invoked with the EX input command, main store controller (MASC) phase 95 accepts input parameters from EX:LDPARM. The MASC phase 95 allows the user to supply the address range to be tested on the MASC (default is entire address range); the data pattern and complement (default=0xffffffff and complement=0x0000000); and the refresh rate, 2 ms standard or 4 ms extended (default). To execute MASC phase 95, use the following procedure: 1. Determine the address range of the main store arrays (MASAs) to be tested by using the information shown in Table .AW TAC/. The MASC 0 starting address is X'0. End addresses are determined by the number and type of MASAs. 2. Using the STANDBY or OOS CU, enter: EX:CU=a,MASC=b:<optional key words>,PH=95,TLP; where a = control unit (0 or 1) and b = main store controller (0 or 1). (Optional key words are defined in AT&T 235-600-700, Input Messages Manual.) The machine responds with a message that the diagnostic started and gives a task (or slot) number. 3. Enter: EX:LDPARM:CU=a,MASC=b:,SA=H'[starting address], EA=H'[ending address]REF=4,PAT=H'5A5A5A5A; Other good choices for PAT value are as follows: A5A5A5A5 FFFFFFFF 0 Use the information shown in Table .AW TAC/ for starting and ending address. The machine responds with a message indicating the chosen parameters and runs the diagnostic. 4. If the diagnostic fails, use the information generated by the TLP option to correct the problem. Rerun phase 95 diagnostics starting with Step 2. 5. Restore the CU (RST:CU), softswitch (SW:CU), and run the same diagnostic sequence on the other CU. Diagnostic requests must be inhibited (always denied) while a field update is applied to the diagnostic files. Stop entering manual requests and perform the following procedure to inhibit automatic requests: 1. Enter: INH:DMQ:SRC=a,TINH=b,AINH=c; to inhibit (always deny) automatic diagnostics. The options have the following meanings: SRC a= The source of the requests to be denied. This may be either ADP, REX, or ALL. TINH b= The number of minutes the inhibit is in effect. The default is infinity. AINH c= The number of minutes between warning messages informing the user that an inhibit is in effect. The default is a message every 5 minutes. 2. Observe the following warning message: Warning: DGN:INHIBIT a ACTIVE,REMAINING TIME n MIN or, for an infinite inhibit, DGN:INHIBIT a ACTIVE. 3. The inhibit may be deactivated manually by entering the following commands: Enter: ALW:DMQ:SRC=a; 4. Observe the following output message indicating that the inhibit is deactivated: ALW DGN ENABLED a Only automatic diagnostics may be inhibited. A request to inhibit a manual source is denied, and the following message is output: INH CAN'T INHIBIT A MANUAL SOURCE - source. Also, only a limited number of inhibits may be active at one time. If this limit is reached, further inhibit requests result in the following message: INH TOO MANY ACTIVE INHIBITS. In this case, another source must be allowed or the ALL source must be used in place of all currently active inhibits. To obtain information on the status of a diagnostic, enter: OP:DMQ; The output from this command indicates the slot number [the number on the far left in the sample from OP:DMQ; (Figure .AW G109/)] and the queue assigned to a particular job. Slots that are inactive (are not assigned to either queue) are not displayed. It may be necessary to cancel a request in the waiting queue or to abort a request in the active queue if: o The request was entered by mistake. o A request of high importance is in the waiting queue, and an active queue must be cleared to make room. o An interactive diagnostic is to be executed. o The active and waiting queues of all requests must be cleared for the field update of diagnostic files. This is the procedure to use when aborting or canceling a request. 1. Enter OP:DMQ; The output from this command indicates the slot number and queue assigned to a particular job. (See Figure .AW G109/ for an example of this output.) Note: Slots that are inactive (not assigned to either the active or waiting queues) are not displayed. The source in the output message may be (but is not limited to) one of the following: o ADP: Automatic diagnostic process. o MAN: Manual requests input by the user. o PSM: Power switch monitor. This request is either a remove request on a unit when the request-out- of-service (ROS) key on the unit power switch is activated or a restore request when the ROS key is released. The PSM requests are classified as manual. o REX: Routine exercise. 2. To abort a job in the active queue or to cancel it from the waiting queue: Enter STOP or STP:DMQ:[unit=a,subunit=b][,ACTIVE|,WAITING]; (Valid units and subunits are defined in AT&T 235-600-700, Input Messages Manual.) It is necessary to remove and restore units when applying a hardware change or when you wish to prevent automatic restoration of a unit you suspect may be faulty. To remove a unit, enter: RMV:unit=a; To restore a unit, enter: RST:unit=a:UCL:DATA,CONT; When a unit is removed from service or restored to service, all units under it in the hierarchy are also affected. However, if the CONT option is specified for the restore, the subunits are not affected. If a diagnostic is available for a unit, it is executed before the unit is restored unless the UCL option is specified. The restore is denied if the diagnostic fails. An entire CU must be restored and removed at the same time; its subunits may not be handled separately. Subunits in the DFC and IOP may not be restored unless all units above them in the hierarchy are restored. Occasionally hardware change notices (CN) that require a change in the diagnostic program are issued to the field. These CNs specify changes to the unit control block (UCB) that must be entered into the equipment configuration data base (ECD). These changes should be implemented with the following procedure: 1. Enter RMV:unit=a; to remove the affected unit from service. 2. If the affected unit is a CU, activate key 13 on the emergency action display page. This deactivates any CU force that is in effect. 3. Install any updates to the diagnostic program using standard field update procedures. 4. To diagnose the affected unit and verify that it is ATP, enter: DGN:unit=a:<optional key words>,TLP; (Optional key words are defined in AT&T 235-600-700, Input Messages Manual.) 5. Install the new hardware. 6. Update the UCB for the affected unit using the recent change and verify (RC/V) system. (See the RECENT CHANGE/VERIFY section (Section .RM 3.10/) in this manual to identify the correct RC/V manual to reference.) Four separate transactions are required. Each transaction requires entries to the trbegin, ucb, and trend pages. The transactions are as follows: (a) Change the unit status from OOS or unavailable (UNAV) to unequipped (UNEQ). (b) Change the unit UCB fields to the values as the CN directs. (c) Change the unit status from UNEQ to GROW. (d) Change the unit status from GROW to OOS. 7. To diagnose the unit and verify that the change was installed correctly, enter the following: DGN:unit=a:<optional key words>,TLP; (Optional key words are defined in AT&T 235-600-700, Input Messages Manual.) 8. Activate the recent change to the UCB using the activate RC/V page. 9. To restore the unit to service, enter the following: RST:unit=a:DATA,TLP,CONT; Note: If the change is applied to more than one unit, all steps should be completed for each unit before beginning work on the next unit. The CM and SM diagnostic operations differ from that of the AM described previously. The following is a high level description of the operations of the CM and SM diagnostic functions. Detailed information on specific hardware modules can be found in AT&T 235-105-220, Corrective Maintenance Procedures, and AT&T 235-105-210, Routine Operations and Maintenance Procedures. Demand diagnostics refer to test phases of a particular hardware unit type that are not normally run by either MAN or AUTO requests from all sources. These phases are usually very time consuming and in most cases only useful in finding a small percentage of unusual hardware failures. These demand phases can only be invoked by craft requests that specify a specific range of test phases. For example, if a hardware unit has five test phases numbered 1 through 5, and phases 2 and 4 are demand phases, only phases 1, 3, and 5 would execute under normal circumstances. To force the execution of the demand phases, the craft must enter a message on the MCC of the following form: DGN:unit=x-y-z,PH=1&&5; With this input message, all five diagnostic test phases will execute, including the demand phases. When the craft desires to execute a diagnostic on a CM or SM hardware unit, a message of the following form is entered on the MCC: DGN:unit=x-y-z,PH=a&&b,TLP; The verb DGN requests that a diagnostic be executed. UNIT denotes the unit name of the circuit to be diagnosed, followed by the unit number. The PH qualifier is an option. If specified, only the diagnostic test phases a through b are executed. If not specified, all non demand phases are executed. The TLP qualifier requests that if a diagnostic test fails, the Trouble Location Procedure (TLP) report that identifies the suspected faulty equipment be printed on the ROP. Specific details for all CM and SM hardware unit diagnostics are contained in AT&T 235-600-700, Input Messages Manual. Each SM may have up to eight diagnostics in a running or waiting state due to requests from any or all sources. To view the diagnostic status of a particular SM, the following message is entered at the MCC: OP:DMQ,SM=[SM number 1-192]; A report of the following form will be printed on the ROP: OP DMQ SM 107 LAST RECORD ACTION UNIT SOURCE STATUS RST MCTSI=1-0 AUTO RUNNING DGN TAC=1-0-1 MAN WAITING The report heading either indicates CM for Control Module or the Switch Module number. In this case, the report is for SM 107. The report indicates the action being taken. In this example, the two actions are a restoral (RST) and a diagnostic (DGN). The unit name and number are contained in the UNIT column. The source of the requested action is shown in the SOURCE field. The sources are AUTO and MAN in this example. The STATUS indicates whether the action is either RUNNING or WAITING. It may at times be necessary to have the craft intervene and stop one or more queued or running diagnostics. A two step procedure is required to accomplish this. First, the craft needs to get a dump of the diagnostic queue for the CM or SM in which the diagnostic is to be stopped. This is done by entering the following message on the MCC: For the CM, OP:DMQ,CM; For the SM, OP:DMQ,SM=[SM number 1-192]; A range of SMs is also possible with this command by specifying two SM numbers separated by &&. The report generated will show the status of all running and waiting diagnostics for the CM or selected SM(s). Both running and waiting diagnostics may be stopped. The craft then decides which diagnostic is to be stopped, and enters a message of the following type: STP:DGN,unit=x-y-z; The unit name and number are obtained from the previous DMQ report. Note: The STP:DGN command will not stop diagnostics that are running as a result of a restore done on a piece of hardware. For example, suppose a conditional restore was done on a protocol handler (PH). An OP:DMQ on the SM that contains the PH will show a restore (RST) action is running on that PH. The ROP will proceed to show diagnostics that are running as a result of the restore. To stop the process, the craft should enter STP:RST,unit=x-y-z; or STP:unit=x- y-z;. These commands are valid for both SM and CM processes. When the diagnostic stops, a message will print on the ROP indicating this fact, and the MCC page display for the selected unit will change its status display from OOST to OOS. The unit will be left in the OOS state after a STP command is executed. If the STP command does not stop the desired diagnostic, the following command will always terminate it: ABT:DGN,unit=x-y-z; Use this command with caution. It will always eliminate the requested diagnostic, but does so in a brute force way, causing several audit and assert reports to print on the ROP. After the ABT completes, the hardware unit will likewise be left in the OOS state. Whenever a hardware unit is to be removed from service by the craft for any reason, the following message is entered on the MCC: RMV:unit=x-y-z[,UCL]; If the hardware unit is actively involved in a call, the request will be denied, unless the UCL option is included. A UCL removal request always removes the hardware from service; however, calls set up using the affected hardware will be torn down, causing one or more lost calls. The UCL option should only be used when the customer is willing to accept this service affecting action. Whenever a hardware unit is to be restored to service by the craft, the following message format is entered on the MCC: RST:unit=x-y-z[,STBY][,UCL]; If the hardware is a duplex unit, having two duplicate, redundant circuits, either capable of providing its intended function, the inclusion of the STBY option will restore the requested unit to its standby state. In this case, the mate unit will be providing the intended service. The standby unit is ready to take over control of the active unit at any time it is needed. Omission of the STBY option, results in the selected unit being restored to the active role and the mate unit being made standby. A normal restoral request will execute the hardware circuit diagnostic, and if all diagnostic tests pass, the unit is restored to its active, in-service state. Including the UCL option, omits the diagnostic execution and directly restores the unit to its active, in-service state. Occasionally, hardware changes which are packaged and distributed as Change Notices (CN) require changes in the associated diagnostic program. These CNs specify changes to the Change Level Indicator (CLI) for the hardware circuit and must be coordinated with the new diagnostic program update. The details for coordinating the hardware and software changes are found in AT&T 235-105-231, Hardware Growth Procedures. If an automatic or manual diagnostic encounters trouble, a message is output. There are three basic scenarios for this procedure. When a unit is automatically removed from service, a major alarm is sounded and a message is output to the MCC and ROP. A diagnostic is automatically requested by the ADP with the TLP option specified. You may verify that a diagnostic is in progress by entering OP:DMQ;. If no diagnostic is in progress, begin one by entering RST:unit=a:DATA,TLP;. A TLP circuit pack list will be produced. At the completion of a routine automatic diagnostic (that is, REX), a summary table is printed. Any units that have failed are marked some tests failed (STF), and a TLP circuit pack list is produced. Manual diagnostics also produce an output message. If the TLP option was specified, as is recommended, a TLP circuit pack list is also produced. The failed test data in the output message and the TLP circuit pack list are your tools for locating and correcting trouble. The diagnostic output message consists of a header line followed by the failed test data (if failures occurred). (See Figure .AW G110/ printout of diagnostic failure.) The header line identifies the unit (for the CU and subunit), the phase number, and the phase results as described in Table .AW TAA/. If there are test failures or if all available tests are not run, the number of test failures and the conditional test result words appear in parentheses on the header line. The two conditional test result words are 64 bits numbered from 0 to 63 starting from the right. When a bit is set, it indicates why some or all of the phase tests were not run. See Table .AW TAB/ for explanation of conditional test results. If there are test failures, the header line is followed by a 5-column failing test display. The TEST column identifies the failing test numbers in the phase. Unless the RAW option was specified on the diagnostic request, only the first five failing tests will be printed. The MASK column indicates which bits are actually included in the test. A one in the MASK means that bit is part of the test. The ACTUAL column displays the results read from the hardware under test. The EXPECTED column displays the expected results. The MISMATCH column indicates which bits failed the test. The data in the MISMATCH column is derived from the ACTUAL, MASK, and EXPECTED data in the following manner. First, the ACTUAL and EXPECTED data are EXCLUSIVE ORed, which yields a one in the bits that are not in agreement. Second, the results of the EXCLUSIVE OR are logically ANDed with the MASK to filter out disagreeing bits not included in the test. The ACTUAL, MASK, and EXPECTED data are not available for some AT&T 3B20D computer peripheral unit diagnostics. When this is the case, ``N/A'' (not available) is printed for the ACTUAL, MASK, and EXPECTED data. Failure data for faults detected in main store is also output in the form of a histogram. (See Figure .AW G111/ for an example.) A data pattern is 40 bits wide: 32 data bits, 4 hamming bits, and 4 parity bits. The address spectrum is divided among several memory arrays (circuit packs) as shown in Table .AW TAC/. When the data pattern read back from the store does not match the one that was written, a failure has occurred. Memory testing stops after the first 100 faults are detected. A detailed failure analysis is output for the first fault. This includes the failing address, expected value, received value, mismatch for both the data and parity bits, and a dump of three main store controller registers. The number of addresses that failed and a list of the first five failing addresses is next followed by the memory failure histogram which shows: o For each data, hamming, or parity bit, how many times the bit failed as a 0 and how many times the bit failed as a 1 o For each address bit, how many times the bit failed as a 0 and how many times it failed as a 1 o How many multibit errors were detected o How many error-logic failures were detected (single bit-error indication on a multibit error). The numbers in these columns can be used to determine the location and extent of the problem. For example, in the DATA FAIL columns, a 1 indicates a single memory-cell failure and a 100 indicates a fault on a data signal path. If the counts for a particular bit are approximately equal, the bit is probably good. But, if on all failures a particular bit always has the same value, then the bit is stuck at that value. Note: The upper address bits select the memory array. They usually appear as stuck bits, because the effect of a fault is usually isolated to one memory array circuit pack. In the example shown in Figure .AW G111/, data bit 24 is stuck at 0 but only when address bit 2 is 0. The address bit is the array half-select. Therefore, since the main store under test contains TN14s, the fault is that the data bit 24-signal path is stuck at 0 for the A-half of memory array 2. The TLP option of the DGN command produces a list of suspected faulty circuit packs when a diagnostic fails. A circuit pack list is output after the diagnostic has completed. Figure .AW G112/ is a sample TLP circuit pack list. The pack most likely to be faulty is listed at the top followed by other suspected packs in descending order. For each pack, the following information is given: o Code (circuit pack type) o EQL (equipment location) (for example, 60-042, where 60 = vertical coordinate in the cabinet and 042 = horizontal coordinate in the cabinet) o SD (schematic drawing) number and the FS and symbol (SYM) number within the SD o Unit in which the circuit pack resides (if not the unit under diagnosis) o WT (Weight) on a scale from 1 to 10 with the circuit packs most likely to be faulty given a 10. Note: If the note field is nonzero, consult AT&T 235- 600-750, Output Messages Manual, for further information. At various points within the diagnostic control structure, audits are performed to verify that all is well. These include verification that: o Called functions do not give bad return codes. o Needed system resources are available. o Necessary files can be opened and read or executed. o Hardware errors have not occurred. o Illegal operations are not attempted. If an audit fails, a report is printed on the maintenance terminals. You should respond to an audit report as detailed in the following procedure: 1. If a test fails prior to an audit failure, clear the problem indicated by the test failure. This may also clear the audit failure. 2. Consult AT&T 235-600-750, Output Messages Manual, to determine the reason for the audit failure. It may be due to a situation you can control. For example, an attempt to execute a nonexistent diagnostic phase would cause an audit failure. 3. Save the printout pertaining to the diagnostic request and return it to your technical assistance organization. 4. Consult AT&T 235-600-750, Output Messages Manual, to see if any additional data should be collected and returned to your technical assistance organization. An audit failure within the DIAMON appears as follows: REPT DIAMON ERROR = a ERRNO = b The numbers following ``ERROR='' and ``ERRNO='' are system error numbers. The meanings of these error numbers are defined in AT&T 235-600-750, Output Messages Manual. Whenever a hardware unit diagnostic is executed by the craft or through a fault recovery (FR) request, several output messages are printed on the ROP giving the results of the requested diagnostic. Whenever a hardware diagnostic is completed successfully, messages of the following format are printed on the ROP: DGN UNIT=x-y-z COMPLETED ATP PH a This message indicates that Phase (PH) a of the diagnostic completed successfully, having All Tests Pass (ATP). One message of this format is printed for each test phase that completes successfully. At the completion of all diagnostic test phases, the following message is printed on the ROP: DGN UNIT=x-y-z COMPLETED ATP This message indicates that the hardware unit diagnostic has completed its execution, and that all tests that were executed were done so successfully. Whenever a hardware unit diagnostic fails any diagnostic test phase, the following messages are printed on the ROP: DGN UNIT=x-y-z STF PH a SEG b TEST c MM H'hhhh This message indicates that Phase a, Segment b, Test c failed. The MisMatch (MM) field gives the test data for the indicated test. Further details of the use of the MM data is found in AT&T 235-105-220, Corrective Maintenance Procedures. DGN UNIT=x-y-z COMPLETED STF PH e This message indicates that the Phase (PH) e completed execution, and that Some Tests Failed (STF) during its execution. DGN UNIT=x-y-z COMPLETED STF When all requested test phases have completed execution, this message is printed to indicate that the requested diagnostic has completed; and that during its course of execution, one or more tests have failed. Whenever hardware unit diagnostic program is executed and any test fails, a hardware fault has been detected. If the Trouble Location Procedure (TLP) option has been included in the diagnostic input message, and a hardware failure is found, a TLP list is printed on the ROP indicating the suspected faulty equipment for the diagnostic test phase that failed. Figure .AW G113/ is a sample TLP list for a diagnostic failure. The intent of the TLP report is to give the location in the switching office of the hardware unit that failed the diagnostic. The AISLE is the equipment aisle, the MODULE is the switch module, in this example, SM number 10. The CABINET gives the cabinet number of the specified switch module, in this case, LTP 2. CODE refers to the circuit pack code that is at fault. The EQL is the equipment location in the specified CABINET. The first number is the vertical distance in inches from the floor to the faulty circuit pack. The second number is the horizontal distance in eighths of an inch from the left side of the specified cabinet. These dimensions are rubber stamped on the equipment cabinets. The TYPE field specifies the circuit under test as ---, ONL meaning an on line interfacing circuit, or HLP for a helper circuit. If some additional information is required, such as specific repair procedures or precautions, the NOTE field will contain a number. This number is defined in AT&T 235- 600-750, Output Messages Manual, Appendix. The routine exercise capability provides the following: o Scheduling of the routine diagnostics for hardware units of all SMs o Scheduling of the routine diagnostics for the CM based hardware units o Enhanced scheduling flexibility o Control for the previous schedulers o An improved craft interface o Scheduling of electronics loop segregation (ELS) tests and fabric tests of grids. The purpose of REX is to routinely schedule testing in the CM and/or SMs, in order to detect latent faults present in in- service units. In other words, REX is an automatic scheduler of tests. The types of tests that REX schedules are dependent upon the module type (CM or SM). a. In the CM, two types of tests are available for scheduling. They are full and partial diagnostics. See the descriptions that follow: o Full diagnostic (DGN): Results in a conditional restore request including the trouble location process (TLP) option. For details of the TLP option, refer to the TLP subsection within this manual. o Partial Diagnostic (switch): Results in a soft switch of the pump peripheral controller (PPC), the foundation peripheral controller (FPC), the office network and timing complex (ONTC), and effective with the 5E6 software release, the communication module processor (CMP). No diagnostics are executed. b. In the SM, three types of tests can be specified: o Full Diagnostics: Same results as indicated for CM. o Fabric Exerciser (FAB): Tests the operation of the gated-diode crosspoints (GDX) in the line unit (LU) concentrator grids or grid boards. It requests a path to each crosspoint to be tested by calling peripheral control (PC) path hunt routines. A series of tests are then performed on the crosspoint and its associated path using a high- level service circuit (HLSC). o ELS: Tests customer lines to determine a suitable network balance necessary to reduce the amount of potential echoing in the transmission path. Office data is updated, as needed, storing the proper balance network value to be used in call setup. Each module has its own REX schedule. A schedule is defined as the start time and duration for each test type along with a verbose option flag. The REX schedule resides in the office dependent data (ODD) data base and can be changed and/or displayed via recent change/verify (RC/V) mechanisms. The REX program obtains the schedule from the ODD relation ``rlRXSCHD'' for the current day at midnight. Therefore, if the REX schedule is modified, the new schedule is not effective until the midnight following the change. Also, REX provides the ability to turn off the REX schedule without modifying the data base. This can be accomplished by putting a module test type in an inhibit state via the INH:REX command. The inhibit state remains active until it is removed via the ALW:REX command. The inhibit status is printed automatically at midnight so that the craft can keep track of what modules have been inhibited or what modules have individual units inhibited for test. REX can be inhibited or allowed for a range of SMs with one input message. Prior to the implementation of this capability, REX had to be inhibited or allowed by entering a message for each specific SM. The following input messages illustrate a range of SMs being set up to allow and inhibit REX: o ALW:REX,SM=1&&20; o INH:REX,SM=1&&20; Two CM models are included in the 5ESS switch architecture: communication module, model 1 (CM1) for configurations up to 48 SMs and communication module, model 2 (CM2) for configurations up to 192 SMs. For the CM, REX schedules full diagnostics for the message switch (MSGS) and the ONTC. Growable units, that is, module message processors (MMP), are scheduled as they become fully operational in the ODD data base. In both CM1 and CM2, the MSGS consists of the message switch control unit (MSCU), the PPC, the FPC, the MMPs, and effective with the 5E6 software release, the CMP. o For the CM1, the ONTC consists of the link interface (LI), the network clock (NC), the message interface (MI), the time multiplexed switch (TMS), and the dual link interfaces (DLI). o For CM2, the dual message interface (DMI) replaces both the MI and the LI to account for both the dual and single fabric configurations of the TMS. The role of the NC, TMS, and DLIs remains the same for CM2 as in CM1. In the SMs, the module controller/time slot interchange (MCTSI) and its associated peripheral units are scheduled for full diagnostics. The number and types of peripheral units scheduled are based on how the SM is equipped. Certain precautions must be observed when constructing a REX schedule for the CM and SMs. The CM REX should not be scheduled to run at the same time as the AT&T 3B20D REX because all active CM diagnostics are aborted when a soft switch of the Control Units (CU) is executed. This could leave the ONTC or MSGS in a simplex configuration. The SM REX schedule must be planned so that DGN, FAB, and ELS tests do not run concurrently. Overlapping of these tests results in resource contention which may abort some exercises, cause tests to be skipped, or leave equipment out of service. For 5E7 and earlier software releases, a C-language based program called the Operations Support System (OSS) REX Scheduler Program is available to assist field technicians with the construction of a viable REX schedule. Although intended for use in the SCCS environment, the OSS REX Scheduler Program will run on any UNIX operating system. Customers may obtain the OSS REX Scheduler Program from the Customer Information Center by paying shipping charges only. Effective with the 5E8 software release, the new Automatic REX Scheduler feature can be used to calculate and update the REX schedule. This feature, which is integrated into the 5ESS switch software, performs the same logical function as the OSS REX Scheduler Program. For more detailed information, refer to Section .RM 3.20.5/, OSS REX Scheduler Program, and Section .RM 3.20.6/, Automatic REX Scheduler. AT&T 235-105-210, Routine Operations and Maintenance Procedures, devotes an entire section to REX, the OSS REX Scheduler Program, and the Automatic REX Scheduler. The following list identifies what is covered: o Purpose of REX o REX Scheduling o REX manual commands o REX automatic scheduling o REX MCC pages o REX scheduling algorithms o REX scheduling recommendations o REX scheduling conflicts o OSS REX Scheduler Program o Automatic REX Scheduler o Diagnostic failures o Initiate REX scheduling o Analyze EXC REX output message o Stop test types of REX o Request summary of valid REX test types o Analyze OP REX (DGN, FAB) printout o Analyze OP REX (ELS) printout o Request REX status of CM and SM(s) o Analyze OP REXINH output message o List units that are inhibited for REX o Analyze OP REXINH unit output message o Inhibit valid test types for REX o Inhibit scheduling of DGN REX test for a unit o Allow one or all valid test types of REX o Allow scheduling of a unit for REX DGN test o Execute OSS REX Scheduler Program. The OSS REX Scheduler Program is a non-switch resident, support-system based program developed to ease the process of customizing a REX schedule for 5E7 and earlier central offices. (For 5E8 and later offices, see Section .RM 3.20.6/, Automatic REX Scheduler.) The process of customizing a REX schedule is divided into four major phases as follows: 1. Data Collection: The user is prompted for pertinent central office equipage data that is needed to create a REX schedule. 2. Data Processing: The program uses formulas and algorithms designed to reduce resource contention and generates a REX schedule tailored to the configuration of each central office. 3. Recent Change Script Generation: The program creates a recent change file (valid for 5E6 and 5E7 software releases) that can be executed from the SCC using the SEND:OFC command. This allows the user to observe message acceptance or rejection and to stop and restart message transmission using available SEND:OFC command options. The contents of the recent change APPTEXT file will cause the 5ESS switch to update recent change views 8.1 and 8.3 automatically. For example, SCC command send:ofc;channel five.smtc, file rex.five! will send the APPTEXT recent change messages in file ``rex.five'' to the central office over its second maintenance channel. Note: To prevent loss of messages on the logging channel, the SCC should use a recent change channel (if available) or a second maintenance channel to execute the recent change file. 4. REX Schedule Output: The program also generates a printout of the REX schedule that resembles RC/V Views 8.1 and 8.3. If you elect not to use the recent change script generated previously, this printout simplifies the process of transcribing data from the schedule into the 5ESS switch data base. It also reduces the likelihood of input errors. The OSS REX Scheduler Program has the following three limitations: 1. Number of Switching Modules: The program cannot create a viable schedule for central offices with more than 80 switching modules. This limitation is due primarily to time frame considerations. 2. Number of LUs and ISLUs Per SM: For the reason cited previously, the program cannot create a REX schedule for central offices that have: o Switching Modules with more than 5 ISLUs, or o Switching Modules with 4 ISLUs and more than 1 LU, or o Switching Modules with 3 ISLUs and more than 4 LUs. 3. Number of GDSU/TTF Responders (TN304B): The maximum number of SMs concurrently executing ELS tests cannot exceed the total number of TTF responders available for testing. The program reserves one TTF responder for ROTL and trunk testing and then schedules as many SMs as possible for ELS testing. It creates an ELS overflow list to identify the SMs that could not be scheduled for the required number of hours. For these cases, one alternative is to extend the duration of REX by either starting it earlier or letting it run longer. The office should also consider adding a responder board. For additional information on the OSS REX Scheduler Program and procedures for its use, refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures. The Automatic REX Scheduler, a 5E8 software release feature, eliminates the need to manually construct a REX schedule for the central office. The tool performs a data base read of the ODD to determine office equipage and uses this information to construct an optimum REX schedule. The Automatic REX Scheduler offers several options including automatic updating of RC/V views 8.1 and 8.3 and printing of the REX schedule on the ROP. Note: Verify that RC/V view 8.3 exists before executing the Automatic REX Scheduler with the update (UPD) option. If RC/V view 8.3 does not exist (as with a newly grown SM), it must be inserted or the Automatic Rex Scheduler will fail. The basic command, entered at the MCC or TLWS, is as follows: EXC:SCHED,[ALL|REX|ALIT]; where the choices in brackets indicate the scheduling desired, whether REX, ALIT, or ALL (both). Details of input and output messages to the ROP are shown in AT&T 235-600-700, Input Messages Manual, and AT&T 235-600-750, Output Messages Manual. Options allow the user to specify (1) the days of the week for which REX is to be scheduled, (2) the REX start time, and (3) the REX duration. The user also may specify ALIT end time and duration, along with the option to update the ODD with the new REX schedule. When options are not specified, the program will use a set of default options. Default options are as follows: REX REX runs 7 days a week, beginning at midnight and running for 6 hours. CM REX The CM REX begins at 1:00 a.m. and runs for 5 hours. Note: ALIT runs every day, regardless of options. One of the goals of the Automatic REX Scheduler is to construct a REX schedule that will result in the testing of all equipment in the central office within a one-week period. If this is not possible, the program informs the user how much of the equipment (stated in percent) will be diagnosed within a week (if the UPDATE option is specified, the new schedule will go into effect anyway). The user may wish to try different values for the number of days and hours allowed for REX testing in order to achieve more complete REX coverage. The Automatic REX Scheduler also informs the user if SM REX and ALIT overlap or if CM and AM REX schedules overlap. (This will not happen unless the user-specified options override the default options.) The ROP output shows the calculated REX schedule for each day of the week, listing all of the SMs that will be tested on any given day. This list is generated for each REX type (DGN, FAB, and ELS). The REX and ALIT start times and duration, which remain constant for each day of the week, are printed at the top of each form. The Automatic REX Scheduler should be used for all installing offices, after equipment growth that changes the office configuration, or if there is a change in the number of days or hours available for REX testing. The scheduler may be invoked any number of times to try various combinations of REX days and hours because changes to the REX schedule take effect only at midnight. For example, a change to the REX schedule made at 10:00 p.m. will not go into effect until the following day. For additional information on the Automatic REX Scheduler and procedures for its use, refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures. There are several changes in the philosophy of printing switch maintenance for IM (SMIM) peripheral fault recovery (PFR) messages. Originally, all SMIM PFR output messages were printed at the ROP, including those indicating that no recovery action had taken place (``ANALYSIS ONLY''). Through analysis of various field sites, approximately 80 to 90 percent of all PFR output messages contained a recovery action of ``ANALYSIS ONLY.'' For 192 SM offices, this would result in PFR consuming 10 percent of AM real time for the printing of ``ANALYSIS ONLY.'' One of the objectives of the SMIM large office enhancements capability is to decrease the AM real-time usage for printing of PFR output messages to under 1 percent of total AM real time. The changes made to SMIM output message processing are as follows: a. Only alarmed (minor, major, critical) PFR output messages are printed at the ROP. b. All PFR output messages sent to the AM are logged. c. The PFR output messages with recovery actions of ``ANALYSIS ONLY'' and ``NO RECOVERY ACTION TAKEN'' are not sent to the AM. The remaining messages are logged. d. The PFR output messages are separated by peripheral unit type into unique message classes. This allows maintenance personnel to control routing of PFR output messages based on unit type. e. Summary output messages can be used to alert maintenance personnel of units experiencing transient peripheral errors that do not cause a recovery action to be taken. Information contained in the following sections can help maintenance personnel track faulty or marginal hardware through the use of summary output messages and message classes. The following input/output commands can be used to track faulty hardware: o The input message command OP:PERPH,SM[=a&&b][,CLR],SUM=c; is used to request a summary of peripheral transient errors on SMs. This command also can be used to clear error counts in a given SM. o The input message command SET:PERPH,SM=a[&&b],VERBOSE; requests that the verbose status in a single SM or a range of SMs be set. o The input message command CLR:PERPH,SM=a[&&b],VERBOSE; is used to clear the verbose status in a single SM or a range of SMs. o The output message OP PERPH SM=a SUM=UNIT SUMMARY NOT AVAILABLE provides a response to the OP:PERPH,SUM=UNIT command. It indicates there is no summary data from the indicated SM due to lack of response from the SM. o The output message OP PERPH SYSTEM UNIT ERROR SUMMARY provides a systemwide SM peripheral transient error summary and gives an overall indication of transient errors that occurred on peripherals in a given SM. This message does not provide counts for all peripheral errors, but only for those errors that do not cause a recovery action to be taken on a circuit. o The output message OP PERPH SYSTEM ERROR SUMMARY provides a summary of transient peripheral errors that have occurred on SM peripheral units. This message gives an overall indication of transient errors that have occurred on the SM(s). Refer to AT&T 235-600-700, Input Messages Manual, and AT&T 235-600-750, Output Messages Manual, for a complete explanation of each message listed. The method for investigating peripheral problems is designed to work in a step-by-step procedural fashion. By using both the system error summary and unit error summary output messages, maintenance personnel can obtain a ``pattern'' of where errors are occurring. 1. First, it needs to be determined which SMs are taking peripheral errors. This information is printed daily at 7:00 a.m. in the system error summary output message, at which time the system wide error counts are also cleared. The automatic system error summary message contains counts for only the 20 SMs which have taken the most errors in the last 24 hours. To get error counts for all of the SMs in the system, enter the following message: OP:PERPH,SM,SUM=SYS; Figure .AW G114/ is an example of the resulting output message. It is important to remember that these error counts reflect only the errors which have occurred since 7:00 a.m. If the ERRCNT column is blank for an SM, that means that the information was not available because the SM was not able to communicate with the AM. From this information, the SMs which are taking the most peripheral errors can be found. These are the ones which should be targeted for investigation. If only a certain range of SMs needs to be examined, the range can be specified in the OP:PERPH input message when entered as follows: OP:PERPH,SM=1&&20,SUM=SYS; This gives a summary for all SMs between 1 and 20. 2. Next, find out which kind of peripherals on the SMs are taking the errors by entering the following command: OP:PERPH,SM=a[&&b],SUM=UNIT; This command can be entered to specify each SM or a range of SMs. Error counts in the SM are not cleared automatically; they are cleared by maintenance personnel using the CLR option (as shown in Step 6). Figure .AW G115/ is an example of the report from each SM. In this example, the line unit (LU) would be the unit to target for investigation. 3. Set the message class to print for the unit targeted for investigation by entering the following command: CHG:LPS,MSGCLS=HW_MON,PRINT=ON; All the unit type message classes are logged by default, so the previous command allows all the messages for that unit type to be printed, as well as logged. If it is desired to have the messages only printed and not logged, enter the following command: CHG:LPS,MSGCLS=a,PRINT=ON,LOG=OFF; 4. At this point, the peripheral error messages will be seen when an error results in a recovery action on that peripheral (for example, a remove and restore of the peripheral). To see all peripheral error messages for the unit being investigated, use the following command for the SMs targeted in Step 1. Note: Do not set the VERBOSE mode in more than 10 SMs; this will cause the loss of ROP messages by increasing the number of messages going to the AM. SET:PERPH,SM=a[&&b],VERBOSE; The VERBOSE mode also can be set with poke 412 on MCC Page 1800 (Inhibit and Recovery Control) causing display message PFR MSG VERBOSE to backlight. 5. If the problem units are taking control interface (CI) errors or time slot interchanger (TSI) PIDB parity errors, it is also useful to inhibit brevity control in the targeted SMs with the following command, due to the large number of messages which these types of errors generate. This allows more messages to go to the AM. Brevity control should not be inhibited for more than 10 SMs, otherwise messages to the ROP may be lost. INH:BREVC,SM=a[&&b]; Poke 609 on MCC Page 1800 also can be used to inhibit the SM brevity control. 6. Wait for the desired information to come out on the ROP. Once the investigation is completed and problems are cleared, the controls should be returned back to their default state as follows: ALW:BREVC,SM=a[&&b],VERBOSE; or poke 709 on Page 1800 CLR:PERPH,SM=a[&&b],VERBOSE; or poke 512 on Page 1800 CHG:LPS,MSGCLS=a,PRINT=OFF,LOG=ON; If more than one message class was changed, the following command can be used to restore the previous message class status: CHG:LPS,MSGCLS=ALL,FROMBKUP; The error counts on a per-unit basis can be cleared in the SM using the following command, to see new patterns as they emerge: OP:PERPH,SM=a[&&b],CLR,SUM=UNIT; For 5E6 and later software releases, HW_MON is the message class for all peripheral units. Suppose that TSI DI-ERR-BUFF errors have been coming out occasionally, but the peripherals which are the source of the problem are unknown. 1. First, one needs to determine which SMs are taking peripheral errors. Enter the following command to get the counts for all the SMs in the system: OP:PERPH,SM,SUM=SYS; The resulting output message is shown in Figure .AW G116/. From this information, it can be seen that SMs 8 and 10 should be targeted for investigation. 2. Find out which kind of peripherals on these SMs are taking the errors. Enter the following commands: OP:PERPH,SM=8,SUM=UNIT; OP:PERPH,SM=10,SUM=UNIT; OP:PERPH,SM=3,SUM=UNIT; Figure .AW G117/ is an example of the report from each SM. From this information, it is determined that the peripherals to be investigated are the DCLU, LU, and DLTU. 3. For the 5E6 software release, set the message class to print for all peripheral units. Enter the following command: CHG:LPS,MSGCLS=HW_MON,PRINT=ON,LOG=OFF; For 5E7 and later software releases, enter the following command: CHG:LPS,MSGCLS=PFR_MON,PRINT=ON,LOG=OFF; 4. In order to see all peripheral error messages for the unit which are being investigated, use the following command for the SMs which were targeted in Step 1. (Remember: The VERBOSE mode should not be set in more than 10 SMs, or this will cause the loss of ROP messages by increasing the number of messages going to the AM.) SET:PERPH,SM=8,VERBOSE; SET:PERPH,SM=10,VERBOSE; SET:PERPH,SM=3,VERBOSE; The VERBOSE mode also can be set with poke 412 on MCC Page 1800 (Inhibit and Recovery Control) causing display message PFR MSG VERBOSE to backlight. 5. Inhibit brevity control in the SMs with the following command. (Again, this should not be done for more than 10 SMs, otherwise messages to the ROP could be lost.) INH:BREVC,SM=3; INH:BREVC,SM=8; INH:BREVC,SM=10; Poke 609 on MCC Page 1800 also can be used to inhibit the SM brevity control. 6. Now, wait for the desired information to come out on the ROP. Once the investigation is finished and problems are cleared, the control should be returned to their default state as follows: a. Allow brevity control: o ALW:BREVC,SM=3; o ALW:BREVC,SM=8; o ALW:BREVC,SM=10; b. Clear the verbose mode: o CLR:PERPH,SM=8,VERBOSE; o CLR:PERPH,SM=10,VERBOSE; o CLR:PERPH,SM=3,VERBOSE; c. Set the message classes back to their default logging state by use of the following command: o CHG:LPS,MSGCLS=ALL,FROM BKUP d. The error counts in all the SMs that are on a per- unit basis in the SM can be cleared using the following command, in order to see new patterns as they emerge. o OP:PERPH,SM=1&&16,CLR,SUM=UNIT; While the volume of teletypewriter (TTY) output messages generated from within the integrated services digital network (ISDN) peripherals is expected to be modest, the total equipage in a medium-to-large size 5ESS switch may be very large with a correspondingly high potential for a large quantity of output messages. The possibility of generating such a high volume of messages makes it necessary to throttle port processor messages unless maintenance personnel specifically requests them. Therefore, separate print controls are provided for each of the ISDN peripheral units. The various input messages for peripheral print control are listed as follows (in MML). Refer to AT&T 235-600-700, Input Messages Manual, and AT&T 235-600-750, Output Messages Manual, for a complete explanation of these messages. o CHG:PRNTMODE=a, SM=b, {PSUPH=b | PI | PP}; This input command is used to change the print control status of the specified peripheral. If the print mode is set to ``ON,'' output messages from the specified unit are logged in the AM as they occur. If the print mode is set to ``OFF'' (the default), output messages are not sent to the AM for logging or printing. When the print mode is off, output messages are temporarily logged within the unit itself and may be retrieved via the ``HISTORY'' option or the OP:HISTORY input message. o OP:HISTORY, {PSUPH=a | CHNG=a | MCTSI=a,PI} [,PRNTMODE=a]; When history is requested, the output messages logged in the specified unit are printed on the ROP. This input command also provides the option of changing the print mode status (see the CHG:PRNTMODE command described previously). o OP:POSTMORT, MCTSI=a,PP; This input command requests port processor postmortem reports to be printed on the ROP. Postmortem reports consist of those output messages that were logged in the port processor at the time of the initialization. Refer to the OP:POSTMORT and RLS:POSTMORT messages in the input message manual for the complete explanations. o OP:STATUS, {PSUPH=b | CHNG=b | MCTSI=b,PI}; This input command requests summary information for the specified unit. The status information printed on the ROP includes print mode status, overload status, and initialization summary information. Note: The descriptive text and detailed procedures within AT&T 235-105-210, Routine Operations and Maintenance Procedures, can be very helpful when maintenance personnel are concerned with the routine operations of the 5ESS switch. Routine tests are run by the terminal maintenance subsystem to assure trunk and line integrity. Routine tests are run on circuits that are assumed to be in good operating condition. These tests can be implemented either automatically or manually. Flexible scheduling of automatic trunk testing is possible through automatic progression testing (APT). In APT, a test history keeps track of information concerning the tests. This allows interruptions of the testing cycle when the trunks are needed for service. When traffic subsides, the testing resumes where it left off. Test results are analyzed and displayed locally at a remote testing location. Note: The APT is disabled in a 5ESS switch for AUTOPLEX System 1000. The ATTS is primarily used to automatically test trunks for a 5ESS switch for AUTOPLEX System 1000. (The ATTS is a secured feature that can be purchased independently for use in regular 5ESS switch applicatioins.) The ATTS schedules routine testing on a periodic basis and is capable of supporting multiple, independent schedules of test sessions. See Section .RM 3.5.1.6.2/ for additional information on ATTS. Routine tests can be classified as operational or transmission and encompass the following objectives: a. Verify the operational characteristics of interface and carrier facilities and distant office equipment. b. Verify the end-to-end ability to detect and send signaling and supervision. c. Routinely exercise the interface circuits in a distant office. d. Verify the operational characteristics of digital carrier voice and data trunk facilities through the use of a digital-circuit loopback and transmit capability (loopback/108-type test line). One of several test actions can be selected for each trunk. The 5ESS switch supports incoming test calls for operational tests. The automatic line insulation test (ALIT) is the operational test for lines. The ALIT is an automatic test system that scans lines and identifies faults before they become service affecting. The 5ESS switch performs all the functions of the 105-type test line and responder. Manual transmission tests utilize the AC and DC jacks and portable test equipment to accomplish transmission testing. This testing is performed at the TLWS. Refer to Section .RM 2.7/ of this manual for more details concerning the different transmission tests that can be implemented via the TLWS. This backup is done any time changes to the office text or data are made permanent. This includes software updates and data base recent changes. The data base recent changes consist of office dependent data (ODD) and equipment configuration data (ECD). It consists of saving the changes from memory to MHD 0 and 1. When the memory changes have been made permanent, they are available on disk for automatic recovery situations which require booting. This backup is performed prior to making changes permanent to data, program, or other files in the UNIX RTR operating system root partitions (dev/root, /dev/db, /dev/etc, and /dev/boot). These changes are the result of software updates or ECD recent changes. The term primary partitions refers to the root partitions. This backup activity depends on the frequency of changes made to the root partitions. It is not necessary to perform this backup for every change made to the root partitions. This backup consists of copying the partitions from the primary to backup partitions and is included in the full office backup procedures. Files in these partitions are identified by pathnames that begin with something other than /no5text. Normally, system operation is performed from the files in the root partitions. This is indicated by the emergency action interface page having item 31 (BACKUP-ROOT) cleared. Backup-root partitions are used only for recovery situations. This means that if backup-root is used to perform recovery operations, the required corrections should be made to the root partitions and control of the system must be returned to the root partitions. No recent changes or software updates should ever be applied to the system while it is running on the backup-root partitions. Introduction: Backup disks contain all software required to provide an operational 5ESS switch. A backup disk may be saved external to the disk drives (shelf copy). Shelf copies are made from each of the disk drives in the system on a scheduled basis. These shelf copies are referred to as MHD 0 and MHD 1 shelf copies. Backups of MHD 0 or 1 are also referred to as primary/boot disk copies. The certified disk is another type of shelf backup. This is a primary disk which has recently been used to boot the AM in the root partitions and has, therefore, been proven to be valid. MHD 0/1 Shelf Disks: Shelf disks are copies of the MHD 0 or MHD 1 disk drive contents. The shelf disks should be labeled for identification and kept in a safe place for system recovery use in the event that data in both primary drives becomes mutilated. Refer to the Memory Alteration Procedures (in AT&T 235-105-210, Routine Operations and Maintenance Procedures) for details on making shelf copies. Shelf copies of MHD 0/1 should not be made more frequently than once a week per drive. The backup schedule should take into consideration the number of changes made to office data and programs since the last backup. When a disk pack is removed from MHD 0 or MHD 1 to make a shelf backup disk, it must be replaced with a disk pack currently used as a shelf copy. The replacement disk pack should be the oldest shelf copy made from the other disk drive. The backup disk packs should be alternated between disk drives to provide the disk pack rotation. Currently, offices employing Century Data System disk drives cannot perform this shelf backup rotation procedure. At least one shelf copy from each disk drive must be maintained at all times. The sequence described here provides one shelf copy from one of the drives and two copies from the other drive. Each time a backup copy is made, it should be made from the disk drive which currently has only one shelf copy. The certified disk is a primary disk copy which has recently been used to boot the AM in the root configuration. Once the system is stable after a UNIX RTR operating system level 3 or greater initialization, the disk used in the boot sequence is used as the latest certified disk. The backup procedure for this disk is covered in the Memory Alteration Procedures section in AT&T 235-105-210, Routine Operations and Maintenance Procedures. The ODD backup to tape is a backup of the office data base and the AT&T 3B20D computer data base on one tape. The ODD tape will contain the current working data base in the following partitions: /dev/db /dev/no5odd1 or /dev/no5odd2 /dev/no5odd1 or /dev/no5odd2 The set of data base partitions to be backed up depends on the contents of the /no5text/rcv/aimrc file. The scheduling of various backup levels is determined by local practices based on the following guidelines. Memory to primary disk backup should be scheduled based on recent change and software update activity. Scheduled intervals for disk backup may vary; they can be performed as often as daily, or as infrequently as monthly. The UNIX RTR operating system root partitions backup should be based on root partition changes associated with the ECD and software update activity. The primary partitions should be copied to the backup partitions before ECD and/or software updates are made permanent. This backup activity is not required for individual changes but should be done for sets of changes. If there is a number of software updates which affect the root partitions, the root partitions should be copied to backup-root and the software updates should be applied. However, if all software update changes were made to files with pathnames beginning with /no5text, then this type of backup is not needed. The no5text partition does not have a backup partition on the disk. Shelf copies of MHD 0/1 should not be made more frequently than weekly on a per-drive basis. The schedule for making shelf copies should consider the frequency of changes made to the data base (ODD or ECD) and the number of software updates installed since the last backup. Whenever the AM requires booting, the disk pack used to perform the boot process should be made the latest certified disk. This guarantees a bootable backup shelf copy. The replacement disk pack should be the oldest shelf copy of a certified disk. The minimum number of shelf backup disk packs is four. Three are required to rotate backup disks between disk drives for the detection of head alignment problems between the drives. One disk is required for the certified disk. Additional shelf backup disk packs may be maintained, if desired (for example, it may be desired to maintain additional certified disks). The frequency of the ODD backup to tape will depend on how often an ODD backup (from main store to disk) is performed in the particular office. The ODD backups should be performed on a regular basis. The appropriate time to schedule an ODD disk image backup to tape is before an ODD backup. This will allow the maximum soak period for the ODD disk image before it is written to tape. Also, whenever the ECD has been altered, the ODD backup to tape should not be used. The full office to tape backup should be used instead. This is because the ODD backup to tape does not cover the ECD. All ODD disk image backup tapes made between two full office to tape backups should be saved. Then, when a new ODD backup tape is made after a full office backup, the oldest ODD disk image backup tape made since the previous office backup should be discarded first. The following schedule for ODD backup to tape is recommended: a. If an ODD backup is performed daily, the ODD disk image backup should be done once a week. b. If an ODD backup is performed twice a week, the ODD disk image backup should be done once every 2 weeks. c. If an ODD backup is performed weekly, the ODD disk image backup should be done once a month. In any event, an ODD disk image backup should be done at least once a month and no more than once a week. In addition to the ODD backup to tape, ODD recovery from tape procedures are provided in AT&T 235-105-210, Routine Operations and Maintenance Procedures, and AT&T 235-105-250, System Recovery. The full office backup to tape consists of all the text and data partitions required to recover an office to a call processing state. Two tapes are required, one tape for the text and one for the data base data. The full office backup tapes should be made based on the following considerations: a. Office backup tapes should be made when the number of permanent software updates in the office reaches a point that makes it desirable to backup the software changes to tape. The number of software updates is office dependent but should not be more than 25. b. Office backup tapes should be made when there is text/data base coupling that results from a recent change or software update change. The coupling and the need to make an office backup should be specified in the software update documentation. c. Office backup tapes should be made whenever the office experiences a UNIX RTR operating system level 3 or higher initialization. The backup should be done after the system stabilizes and the disks are duplexed. d. After a software release retrofit, a set of office backup tapes should be made of the new software release. Once the office is committed to the new software release, the old software release backup tapes should be purged from the office in approximately 2 weeks. Also, the new software release tapes that were used to boot the office during the software release retrofit should be kept as certified tapes until they are no longer usable as backup tapes. The purpose of ODD backup is to provide a sound basis for recovery by allowing the system to recover quickly from a boot or pump. The changes to the ODD may be introduced by regular recent change, customer-originated recent change (CORC), maintenance, and ODBE. Backup of the ODD makes the current memory image (that is, in-core contents) of the ODD permanent on disk. The ODD in the AM and in all the SMs will be backed up during this operation. Origination for ODD backup is under local control. Local control is required for the following reasons: a. The ODD backup is run ``on demand.'' b. After the first initialization of the office, the dynamic head blocks stored in the ODD must be backed up. The frequency of ODD backup depends on the disk space allocated to log regular recent changes and CORCs, and the number of these changes in the system. The percentage of disk log capacity may be obtained by using the OP:LOGSTAT message. In addition to showing the percentage, the output message will also indicate the number of regular recent changes and CORCs in the disk log. It is recommended that the ODD be backed up weekly or whenever the disk log contains 80 percent of the changes that can be restored in 1 hour. To avoid recent change performance degradation, the backup should be run in off-peak hours when system load and recent change input are minimal. When the disk log files reach 80 percent of the changes that can be restored in 1 hour, an alarmed output message notifies local maintenance personnel. When an ODD backup is in progress, CORCs are blocked, and the subscriber receives reorder tone. Similarly, if an attempt to perform an ODD backup is initiated while a recent change is in progress or when the EXC:ODDRCVY=ALL; message is in progress, the backup request is denied. The ODD backup requires disk space for two copies of the entire ODD in addition to the official copy. The first copy is used as a working copy for the file update during backup; while the other copy is considered a ``save'' copy. Errors may be introduced during an ODD backup operation. These errors may be due to bad or lost messages, buffer overwrites, etc. All processes used during an ODD backup are automatically released if a failure occurs. If the backup fails, a manual restart of the ODD backup operation should correct the problem. If not, a more serious system malfunction may be indicated, and technical assistance should be obtained from your AT&T Network Systems Regional Technical Assistance Center (RTAC). The ODD backup does not interface directly with any of the levels of software recovery. If a processor or the system has an initialization during an ODD backup, the ODD backup is normally aborted with no damage done to the official ODD files. The ODD backup can be restarted at another time. After the initialization, a recent change recovery must be performed to reinstate the lost recent changes and CORCs. A stable or transient clear backs out all recent changes and CORCs entered since the last ODD backup. This is because system initialization restores the memory version of the ODD with the disk version created by the most recent ODD backup. The ODD recovery consists of reapplying the backed-out recent changes and CORCs. Records of the recent changes and CORCs are logged in disk files during the updating process. The ODD recovery provides all features needed by maintenance personnel to recover the ODD. The EXC:ODDRCVY input message is usually generated automatically after a system initialization is completed. The output message generated is prefixed with an ``A'' to indicate that the ODD recovery was automatically started. Manual recovery is needed after all craft-initiated system initializations. Manual recovery is also needed after automatic initializations when the system integrity monitor determines that the ODD recovery may be faulty. When manual intervention is needed, the EXC ODDRCVY NOT STARTED alarm message is dumped to indicate that the automatic recovery was not started and that a manual ODD recovery is needed. All recent change activity is blocked until the command has been completed. If a manual recovery is needed and the OP:LOGSTAT message is run, the OP LOGSTAT output message displays a reminder that the ODD recovery has not been performed since the system initialization occurred. Semiconductor devices are constructed to withstand mechanical shocks and drops of a limited nature. However, they are not indestructible and excessive shocks may shorten their life expectancy and/or change their electrical characteristics. o The integrated circuit (IC) packs and their film circuits are usually more susceptible to mechanical shock than conventional circuit packs due to their multiplicity of components and construction. o Damage may result from dirt and other contaminants that wear down the gold contacts. Once the gold plating has been worn off or scratched, an oxidized film may form on the exposed copper. This film may cause electrical noise in the circuit and, if undisturbed for a long time, could open the circuit. o Semiconductor devices and circuit packs in general are sensitive to static charges. Circuit pack IC damage can be attributed to a discharge of static electricity. o For a person to feel the discharge of static electricity, a minimum voltage level of 1,500 to 3,500 volts must exist. A person walking across a floor can generate electrostatic voltages in excess of 12,000 volts. o Tests have shown that ICs can be damaged by discharges of 100 to 200 volts. o Since electrostatic discharges contain little or no current, there is no personal safety hazard. o In addition to electrostatic discharge resulting from an ungrounded person touching a circuit pack, static charges may result from other sources. If a piece of plastic is placed near one end of a circuit pack lying on an insulated table top, it can direct its charge into the circuit pack. o Identifying damage due to electrostatic discharge can be difficult, as in many cases physical damage cannot be seen. A circuit pack or semiconductor device which has been exposed to an electrostatic discharge may: a. Not be affected, that is, work perfectly with normal life expectancy b. Function normally, but with reduced life expectancy c. Function erratically at times d. Stop functioning altogether. Circuit packs are shipped from the factory in corrugated containers which are specially designed to prevent static buildup. Most 5ESS switch circuit packs are shipped in pink antistatic bags. Warning labels are placed on bags and cartons of static sensitive devices. Circuit packs shall be stored in their original factory shipping container. Do not break the seal on this container until ready to use the circuit pack. When returning circuit packs to AT&T locations, ship the packs in the shipping materials in which they were originally packed. The packaging material of new packs received may be used to return the old packs. To facilitate quick repair of defective circuit packs, firmly string tie a completed information tag to the hole above the faceplate of the pack. Circuit packs are shipped with a blank information tag. Circuit pack information tags can be ordered from: AT&T Consumer Products Installation Stock-keeping P.O. Box 265 West Chicago, Il 60185 Defective circuit pack information tags must be completed and string tied to the circuit pack. Packing should take place at a static-free work station. Place the circuit pack in a pink antistatic bag or carton before placing in a regular box. A properly grounded antistatic wrist strap must be worn when handling any circuit pack. The following general guidelines should be followed when handling circuit packs: o The power should be turned off before inserting or removing a plug-in circuit pack, unless specified by test requirements. o Carry the pack (in packing materials) to replacement site before removing it from packaging. Do not remove the pack from the box and walk with it. o Avoid unnecessary removal of circuit packs. o Before replacing a circuit pack, check the identification code to ensure the proper pack is being used. Grounded antistatic wrist straps must be worn for all circuit pack handling. The alligator clip connector of the wrist strap must be connected to a bare metal frame ground. The wrist strap must contact the skin and is not to be worn over clothing. If a static sensitive pack has already been found faulty, do not ignore requirements for handling static sensitive packs. Continued mishandling may create other, more serious, problems with the pack. The following guidelines should be followed to protect circuit packs from electrostatic discharge damage: o A grounded person must never hand an unprotected circuit pack to an ungrounded second person. A static discharge from the ungrounded person through the circuit pack to the grounded person could cause an electrostatic discharge failure. All persons and equipment at a work location must be at the same common ground potential to be static safe. o Do not rub or wipe circuit packs containing ICs. o Work areas must be kept clear of common plastics, because they are a major source of static electricity. When handled, these plastics produce a static charge that will not readily dissipate when grounded. These common plastics must not make direct contact with ICs or circuit packs. Common plastic materials in this classification include polystyrene (styrofoam) packing containers, clear plastic bags, plastic drinking cups, food wrappers, notebooks, and nonconductive plastic solder suckers. The plastic insulation on small hand tools does not represent a static hazard. o Put circuit pack into antistatic bag or carton immediately upon removing it from a frame. o Keep adhesive tape (scotch, masking, etc.) away from sensitive devices. o Do not wax the equipment aisles in the central office. o Maintain relative humidity above the 20 percent level. o When soldering static-sensitive semiconductor devices, the soldering iron must be grounded to the work table which must also be earth grounded. Individuals should also wear an antistatic wrist strap so that all items contacted are at the same potential. o Verify that the resistance between the wrist strap and its connector plug is 1 megohm +-10 percent at least once every week of use. o Make sure that both male and female connectors are clean. o Make sure the circuit pack is aligned with the guide. o Never force the circuit pack. o If unusual resistance is felt, determine and correct the cause before inserting the pack. o Avoid letting any components of a circuit pack scrape the adjacent packs. The following documents can be ordered from the Customer Information Center through your document coordinator by document number. o AT&T 802-001-180: Protective Grounding Systems -- General Grounding Requirements for Common Systems in Central Offices, Radio Stations, and Other Structures o AT&T 802-001-196: Protective Grounding Systems -- General Grounding Requirement for Data Processing Computer Installation Achieving a high level of hardware reliability in the 5ESS switch requires that each office maintain a stock of spare circuit packs. Circuit packs are thoroughly tested by AT&T prior to shipment and therefore do not require site testing. Observe the following guidelines for maintaining a stock of spare circuit packs: o Ensure that instructions for the proper handling and storing of circuit packs are adhered to. (These instructions are described in Section .RM 3.24/ of this document.) o Establish a circuit pack inventory log (Figure .AW G118/) to track all circuit packs including those used for troubleshooting. A Repair Service and Return (RS&R) is a maintenance support service which provides repair services for all 5ESS switch equipment owned by the customer. The 5ESS switch repair procedures are outlined as follows. Please note that the list of service centers and corresponding procedures for readily returnable material and nonreadily returnable material are independent of each other. The following subparagraphs contain the return procedures for readily returnable and nonreadily returnable materials, respectively. 1. The 5ESS switch readily returnable material includes circuit packs and plug-ins located in the SM, the CM, and the processor control cabinets (PCC) of the AM. 2. The Master Item File and/or Regional Control File provide repair locations for 5ESS switch readily returnable material. Readily returnable material should be shipped directly to the specified repair location to receive the optimal replacement interval. Both the Master Item File and the Regional Control File are available from the nearest service center, listed in Table .AW TAD/. 3. The RS&R repair interval is 14 days from receipt of defective material to shipment of repaired material. 4. All defective material submitted for repair should be shipped with a completed RS&R form and a completed ``5ESS Switch Returned Circuit Pack Tag.'' The RS&R forms are typically customer provided. AT&T RS&R forms can be obtained from the Customer Information Center, SD-44-326. Effective with the 5E9(1) software release, the Automated Circuit Pack Return Tag Tool can be used to generate the Returned Circuit Pack Tag. Refer to Section .RM 3.16/ of this document for additional information about this tool. For detailed procedures on its use, refer to AT&T 235-105-220, Corrective Maintenance Procedures. 5. Customers will be notified by mail in cases where material is unrepairable or is uneconomical to repair. Any material disposal occurs as specified by the customer. If defective material is under warranty, unrepairable material will automatically be replaced. 6. Equivalent replacements will only be shipped to customers if the availability of repair parts is expected to exceed the 14-day interval. 7. All repaired material receives a warranty equal to the remainder of the 2-year new equipment warranty or 6 months, whichever is longer. 8. Repair during the warranty period is provided at no charge to the customer. Current post warranty repair prices for readily returnable material can be obtained from your AT&T Network Systems Representative upon request. 1. The 5ESS switch nonreadily returnable material consists of all equipment (including pluggable packs) located in the tape cabinet and the disk cabinets of the AM, terminals, printers, cable rack, and office framework. 2. Repair of nonreadily returnable material is performed by Service Support Center (SSC) personnel during normal business hours, Monday through Friday, 8:00 a.m. to 4:00 p.m. 3. Emergency SSC service outside normal business hours, Monday through Friday, 8:00 a.m. to 4:00 p.m., is billable to the customer unless a maintenance contract applies. Emergency service is billable at a minimum of 4 hours labor. Maintenance contracts are available from AT&T - Network Systems SSC for the entire office or specific units as specified. All SSC servicing of post warranty equipment is billable as incurred unless covered by a maintenance contract. 4. Table .AW TAE/ provides a list of designated SSCs. The nearest SSC should always be contacted as repair assistance is needed. 5. Repair resolution of nonreadily returnable material is customized per occurrence as the resolution could take several forms, such as a phone call diagnosis/resolution, AT&T personnel on site for repair, or submission of unit or portion of equipment to a specified AT&T location for repair. 6. If resolution requires shipment of any material to AT&T for repair as determined by AT&T personnel, existing RS&R routines should be utilized. The normal SSC repair interval is 28 days upon receipt of defective material to shipment of repaired material or equivalent replacement by the SSC. 7. All repaired products receive a warranty equal to the remainder of the 2-year new equipment warranty or 6 months, whichever is longer. Figure .AW G119/ summarizes maintenance support services available from AT&T - Network Systems for the 5ESS switch. Specific information regarding the Spares Exchange Service (SES)-5/SES-5 PLUS services is provided in the following subsection (Spares Exchange Service For 5ESS Switch Equipment). Sparing recommendations for 5ESS switch equipment is provided in ED-5D133-01. This document can be obtained from the Customer Information Center in Indianapolis, Indiana. For additional information or technical assistance, please contact your AT&T Network Systems Regional Technical Assistance Center or the AT&T Account Executive serving your company. The SES-5 and SES-5 PLUS services are additional service offerings intended to be maintenance support services. Their primary purpose is to meet a customer's need for immediate replacement material while minimizing total inventory. They are available to domestic customers with 5ESS switches that are in service or turned over to the customer. Generally, SES-5 and SES-5 PLUS can exchange all AT&T manufactured spare material normally required to support a 5ESS switch and the embedded AT&T 3B20D Computer. All material is new or can be reconditioned/refurbished to new to meet AT&T Network Systems high-quality standards. The spare material covered is considered to be ``readily returnable'' material (for example, circuit packs and plug-ins; not disk drives). The SES-5 PLUS service does not replace the SES-5 service. The SES-5 PLUS offers the customer a fixed annual subscription fee for easier billing administration during both the warranty and the post-warranty period. The SES-5 PLUS service is offered at a yearly subscription price based on the number of switching modules deployed. The host SM and the RSM subscription fees are identical. In order to qualify for SES-5 PLUS service, the customer must agree to have all SMs under contract. The SES-5 and SES-5 PLUS services are intended to be maintenance support services. They are not intended to be the vehicle for obtaining large quantities of materials associated with establishment of central stocks. Orders to establish central stocks should be entered under normal ordering routines. To utilize the services, customers must obtain account numbers. It is recommended that the customer obtain one account number per 5ESS switch location. To obtain an account number, the regional sales offices for the customer's area can help them complete an Account Requisition Form. The purpose of this process is to establish a customer's account against which he may issue orders for replacement parts. The primary information requested is as follows: o Company name, office name, and address o Authorized ``Ship to'' address (can be restricted to one location or multiple locations) o A customer order number o Customer accounting data o Customer approval. The local sales office writes the customer and confirms establishment of the account number. This letter provides basic information on the service and advises the customer that since the account number is used for ordering purposes, it should only be provided to those who are authorized to use it. To obtain an exchange under either SES-5 or SES-5 PLUS, call the toll-free number, 1-800-325-9890. Upon receipt of a call, personnel confirms the customer's eligibility to use the service by requesting their account number. Customers are requested to provide the following information when calling in the order: o Account number o Office name and ``Ship to'' address o Item description and quantity o Required ``on job'' date o CLEI code (Obtained for part to be exchanged) o Shipping instructions o Caller name and number. On emergency orders, customers are provided appropriate shipping information by the transportation organization shipping the material. The delivery of replacement circuit packs is controlled by the customer. Accordingly, it is the responsibility of the calling party to specify the date by which the replacement pack must be delivered. It is expected that emergency deliveries are requested only at such times as the urgency of the situation dictates, such as when no replacement on site is available. The following list contains the different types of delivery intervals available for circuit packs or other plug-in units. Use the number 800-325-9890 to find out what the charge is for each of these delivery intervals. o SES-5: a. Normal service (2- to 7-day service) b. Emergency service (24-hour service) c. Critical service (less than 24-hour service). o SES-5 PLUS: A yearly subscription fee is charged per SM billed monthly. The following items apply to the charges for the replacement of plug-ins under both SES-5 and SES-5 PLUS services: o Under warranty material exchanged not abused - No charge o Out of warranty material exchanged not abused and repairable/updatable - Call 800-325-9890 for price per plug-in unit o In or out of warranty material exchanged abused - Stock order price (800-325-9890) o Material not exchanged within 30 days - Stock order price (800-325-9890). The customer shall return the defective material to Goddard, Kansas, within thirty (30) days of receipt of the replacement, along with a ``Returned Material Authorization.'' The returned package postmark is used to verify the timeliness of the return. The Returned Material Authorization has been prepopulated with all information on file. The customer must complete only the shaded portion of the form which requests the following: o Quantity of parts being returned o Customer signature o Date o How defective part was shipped o Product number (CLEI code) o Weight and number of cartons shipped. AT&T replacement material is shipped in reusable cartons. It is requested that customers use these cartons to return the defective units. When these cartons are not used, it is the responsibility of the customers to use packaging materials that adequately protect the equipment. The customer is also supplied with a preprinted return label which facilitates the return procedure. All SES-5 return material should be mailed to this address for proper billing and crediting: AT&T Technologies SES-5/Dock 44 21999 W. Highway 54 Goddard, Kansas 67052 The individual General Sales Agreements cover the specifics of each customer's warranty; however, the following general guidelines are represented. o During warranty periods, the replacement material carries a warranty equal to the remainder of the warranty period applicable to the material per contract with AT&T, or 6-months, whichever is longer. o During post warranty periods, the replacement material carries a 6-month warranty if the customer pays the replacement price for AT&T manufactured material. If, however, the customer purchases material at the new stock order price through SES-5, the material carries the new product warranty. An audit is a program that verifies software memory for consistency of data. The audit program checks the data base for lost hardware data and broken links between data structures. In other words, audits are used to detect and recover software data errors before the switch's performance is affected. Application audits are administered by the audits subsystem. System audits are administered by the dmert subsystem. (See AT&T 235-600-400, Audits Manual, for a description of this subsystem.) When an audit finds an error in the data base, it immediately begins to correct the software data error. If the audit cannot fix the problem, it is because the error is extensive and higher level audits are necessary, or because the data has an inconsistency that must be repaired manually via recent change (RC) or the office data base editor (ODBE). The use of ODBE is explained in Section .RM 3.13/. Note: The RC is the preferred method. Routine audits are scheduled to run automatically in a continuous repetitive pattern. Scheduled audits run in a continuous repetitive pattern. Also, an audit can be run manually by entering an input message (except in the PH or PI) or as a result of defensive check failures (see asserts section that follows). Audits are run at a low priority to minimize any interference with operational functions vital to call processing. Note: This section is for general information only, refer to AT&T 235-600-400, Audits Manual, for the audits applicable to the 5ESS switch. An audit that runs successfully and does not find any problem will not cause a printout. Only those audits that fail will cause a printout. Figure .AW G120/ is an example of a typical UNIX RTR operating system audit failure. All audit failure printouts contain the letters AUD as illustrated in Figure .AW G120/. Audit failures are normally logged in the AUDLOG and DAYLOG log files. o AUDLOG: The AUDLOG log file contains the system audit failures that are run under the UNIX RTR operating system environment. The user can dump the AUDLOG log file by entering the OP:LOG:AUDLOG input message (refer to AT&T 235-600-700, Input Messages Manual, for details). Only UNIX RTR operating system audit failures are logged in the AUDLOG log file. o DAYLOG: The DAYLOG log file contains the audits (for example, application audits) that run under the operating system for distributed switching (OSDS) environment. Audits logged in the DAYLOG log file are of the message class LAUDIT. The user must specify message class AUDTFST to retrieve the audits, because DAYLOG contains other message classes. Use the OP:LOG:LG=DAYLOG input message to dump the audits. (Refer to AT&T 235-600-700, Input Messages Manual, for details.) The term environment means which processor and which operating system within the processor caused the audit failure to print. The audit environments are as follows: o AM: UNIX RTR operating system o AM: OSDS-operating kernel process (OKP) o AM: OSDS-switching module kernel process (SMKP) o SM: OSDS o CMP: OSDS o PH: OSDS o PI: OSDS The UNIX RTR operating system audits are also known as system audits. These audits run under control of the system integrity monitor (SIM). The SIM is responsible for the integrity of the software that controls the AM hardware. The SIM schedules and dispatches audits in the UNIX RTR operating system environment. Audits that run under control of OSDS are called application audits. In this case, an application means that it is not part of the UNIX RTR operating system. Application software makes the system implement jobs it was intended to perform. Operating system software provides the environment where the application software runs. The OSDS software is part of the 5ESS switch application software. All OSDS audits, in the AM, run under two environments: o OKP: Administers the call processing operations o SMKP: Administers the switch maintenance functions. Audits that occur in the SMs run under control of OSDS- switching module (OSDS-M). The OSDS-M administers call processing and maintenance functions in the SMs. These audits identify the SM number where audit failures occurred. Audits that occur in the primary or mate CMP run under the control of OSDS. The OSDS administers call processing and maintenance functions on the CMP. The audits identify the CMP (primary or mate) where audit failures occurred. Audits that occur in the PH/PIs run under the control of OSDS-switching module (OSDS-M). The OSDS-M administers call processing and maintenance functions in the PH/PIs. These audits identify the PH/PI number where audit failures occurred. Note: AT&T 235-600-400, Audits Manual, identifies the action for audits requiring manual action. The OSDS application audits have an identifier that indicates manual action is required. A manual action required audit is identified by the letter ``A''. Figure .AW G121/ is an example of an audit requiring manual action. An audit with the letter ``A'' is not usually self- correcting. Manual action must be made to the office data base. Whenever a manual action audit appears, make a note and save the printout for analysis. If this problem is not resolved by local maintenance personnel, escalate to the technical assistance organization. Audits that do not have the letter ``A'' at the left side of the printout are considered to be nonmanual action audits. When nonmanual action audits occur, the maintenance personnel should be concerned with the quantity of audits dumped. One or two failures of the same audit on an infrequent basis should not require any special attention by the maintenance personnel. However, when the same audit fails continuously, special attention is required. If the audit is failing continuously, determine the location and source of the audit. If a single SM is printing streams of audit failures, a problem may exist in the office data base or in the hardware (of the specific SM). Figure .AW G122/ is an example of a nonmanual action audit. Asserts, also called defensive checks, are small segments of code within programs or processes that check the validity of data during system operation. Each time a program reaches a defensive check, a test is made to determine if the assertion is true. If it is true (for example, an index is within its specified range), no action is taken and the program continues. If the assertion is false (for example, a resource in one data block is marked as ``idle'' while the same resource in another data block is marked as ``in use''), an assert failure exists. The program calls the assert handler to report the failure and the assert handler then initiates the appropriate action. Asserts perform various kinds of checks, including: o Range checks on pointers, global data, and function arguments to ensure that reads and writes occur within restricted ranges. o Redundancy checks made on duplicate copies of data stored at different locations to detect memory mutilation. o Point-to/point-back linkage checks to prevent network data structure corruption. o Consistency checks between logically related blocks of data. o Message acknowledgment checks to ensure that static and dynamic data agree. o Return code checks to detect bad return values from function calls. The assert handler cannot correct the error directly. After an error is discovered and reported, the assert may trigger an audit or other corrective action via the assert handler (DCF asserts), or it may print a message to the ROP requesting repairs be made to the switch ODD (manual action assert). The assert handler is the software that is called when a defensive check fails. The assert handler is responsible for the reporting and the recovery of an assert. When an assertion is evaluated as false, an assert macro calls the assert handler to process the assert failure. The assert handler dumps related data and schedules the necessary recovery actions by doing one or more of the following: o Dump data relevant to the error. This includes process-related data and data specified by the assert macro, including stack traces and stack frames (see AT&T 235-600-510, Software Analysis Guide, for message analysis information). o Invoke audits o Initiate single-process purges o Initiate selective initialization o Initiate a call for manual action o Escalate/de-escalate the requested recovery action. This type of assert points to a problem that requires manual action. The switch does not correct the problem that caused this assert. In the illustration shown in Figure .AW G123/, the letter ``A'' located at the left of the second line of the printout indicates manual action is required. AT&T 235-600-500, Asserts Manual, identifies the asserts requiring manual action and details the steps to be taken to correct the problem. Both audits and asserts operate in the same data base and perform dynamic verification of the data (that is, data is checked for validity as it is used by the system). However, audits and asserts are different, and the following list indicates the differences between audits and asserts: o Audits are external programs that operate on other programs and data. o Asserts are small bits of software code that are inside the program and operate on programs and data in which they reside. Audits detect errors and recover lost resources; asserts detect errors but cannot recover lost resources. Asserts perform a passive or defensive check for errors or problems. An assert failure such as invoking an audit can trigger a fault-correction procedure separate from the assert itself. The RTA DCF assert failure does not fit the pattern of most asserts. This assert does not have a 5-digit failure number and does not appear in the assert message summary. It is logged in the DAYLOG log file under message class LDCF. Figure .AW G124/ illustrates the RTA DCF error message. Most of the time this assert reflects a problem in the data base that is covered by a 5-digit assert. This means the problem is probably going to be reported twice. Some problems can be reported by an RTA DCF error that does not show up any other way. Therefore, this assert should be watched for excessive occurrences. The assert summary message prints every 15 minutes and contains a list of the assert failures that have occurred during that interval. If no failures have occurred, no summary is printed. The assert code is printed along with the number of occurrences of the assert and the number of discarded assert messages. When a large number of assert messages are generated within a 15-minute interval, a number of these messages can be discarded to prevent needless repetition. Assert messages are discarded if brevity control is allowed (brevity control is normally allowed). If brevity control is inhibited, an attempt is made to print all assert messages. In Figure .AW G125/, assert number 22184 occurred 3 times, and messages from one event were discarded and an attempt is made to print two of these events. Assert number 23439 occurred twice, and messages from one were discarded. Each discarded assert includes several related messages (for example, SPP, RPI, related stack trace/frame messages) all with the same event number. The SPP asserts are logged with all of the other SPP interrupt messages in the DAYLOG log file under the LSPPIN message class. The RPI asserts are logged with all of the other RPI interrupt messages in the DAYLOG log file under the message class LDCF. For 5E6 and later software releases, the summary message is printed and not logged. The DCF SPP assert stimulus message is printed and not logged. The associated assert messages are logged in the DAYLOG log file under the INT-MON message class. The DCF RPI assert stimulus message is printed and not logged. The associated assert messages are logged in the DAYLOG log file under the ASRT-MON message class. Manual action assert messages are printed and not logged. The assert status can be determined by examining switch output messages. To retrieve the logged messages associated with a stimulus message with event number xxxx an OP:LOG:LG=DAYLOG, KV=``EVENT=xxxx''... command would be input from the MCC or a TLWS to dump all logged events associated with event number xxxx. For 5E6 and later software releases, DCF assert stimulus messages are printed and not logged. The remaining DCF assert messages are logged. Be aware of any assert that repeats regularly, whether or not the assert calls for manual action. This indicates a hard or solid problem. Any time a ``manual action required'' assert occurs, the failure should be resolved. Manual action asserts occur when there is an inconsistency in the data base that cannot be resolved by an initialization. When analyzing assert failures, use AT&T 235-600-500, Asserts Manual, and AT&T 235-600-510, Software Analysis Guide. While not all asserts utilize them, there are five basic assert messages from the AM, an SM or a CMP that may be printed on the ROP (see Figures .AW G126/, .AW G127/, and .AW G128/). The messages printed are determined by which assert macro originated the assert. The five messages are as follows: Stimulus Message Contains general information about the DCF, including failing address of the function, event number, etc. Stack Trace Contains the address where the function itself failed and the addresses of functions preceding the failing function. Stack Frame There are two stack frames output to the ROP. One belongs to the failing function and the other to the function that called the failing function. Data Dumps Optional hexadecimal data dumps specified by the programmer. Figure .AW G126/ is an example of an AM assert printout. Figure .AW G127/ is an example of an SM assert printout. Figure .AW G128/ is an example of a CMP assert printout. The packet interface (PI) and protocol handler (PH) asserts are two types of Defensive Check Failures that do not use all five messages. Their output messages consist of a combined stimulus and stack trace message (See Figures .AW G129/, .AW G130/, and .AW G131/). In the PH, the packet switching data structures LLCB, ALCB, and/or LCCB that are implicated during a nonreturning assert are also dumped. These types of assert messages are normally logged and not printed on the ROP. Beginning with the 5E6 software release, the ROP Message Volume Reduction Capabilities will restrict assert output in general to the stimulus message unless complete output is requested. Figure .AW G129/ is an example of a packet interface assert message. Figure .AW G130/ is an example of a protocol handler 2 assert message. Figure .AW G131/ is an example of a protocol handler 3 assert message. See the Assert Analysis section of the Software Analysis Guide for a complete description of these assert messages. Effective with the 5E9(1) software release, the existing switch-resident ODD Population Rule Audit is replaced by the Automated SODD Audit, a version that allows the operating company to maintain a cleaner data base. The new audit is automatically generated from the Population Rule Language, version 5.0, (PRL5) data base population rule source files, ensuring completeness and accuracy. There are three modes of Automated SODD Audit execution as follows: o Full Audit: The full audit validates the ODD with respect to a 149-relation set of population rules. The Automated SODD Audit executes in a continuous loop, auditing the 149 relations from beginning to end in an on-going review of data. The audit starts and suspends itself according to a schedule selected by the craft. Each time the audit resumes execution, it begins where the previous execution was suspended. When the audit is first deployed, a 7-day, 24-hour schedule is set up automatically. The craft can change this schedule to one more suitable to a particular office. Because of the thoroughness of the audit, a single cycle through the full audit may take several weeks. o Incremental Audit: The incremental audit automatically executes after each successful ODD backup (BKUP:ODD). It validates data base transactions (both RCs and CORCs) input since the previous BKUP:ODD. o Entity Audit: The craft can request immediate execution of the audit. Such requests typically limit the scope of an audit to a particular processor and relation, or to a particular data base entity such as a line, trunk, multiline hunt group, or trunk group. Each audit execution produces a summary message that indicates how many errors were found. Additionally, each audit execution produces a detailed log of individual error conditions. The high-runner error conditions are documented by special error messages. Other error conditions are documented by mechanically generated error messages. Tools are provided to output this detailed error log. When deployed, the full audit is automatically started with a 24-hour-a-day, 7-day-a-week schedule. The craft may alter that schedule by using the SCHED:AUD input message. Refer to AT&T 235-600-700, Input Messages Manual, for explanations of input message variables. Refer to AT&T 235-105-210, Routine Operations and Maintenance Procedures, for detailed procedures pertaining to the Automated SODD Audit. The incremental log-file-directed audit is automatically scheduled for execution after each successful BKUP:ODD command. When the craft establishes the backup schedule by using the BKUP:ODD command, the incremental audit schedule is implicitly established. The craft may elect to investigate subscriber complaints by running the Automated SODD Audit on a specific entity, such as a subscriber line or trunk. This is accomplished by entering input message EXC:AUD=SODD to request immediate execution of this entity audit. The resulting error log file is then analyzed to determine if the subscriber trouble is data related. Input messages INH:AUD=SODD,FULL and INH:AUD=SODD,INCR are used, respectively, to inhibit execution of the explicitly scheduled full audit and the implicitly scheduled log-file- directed incremental audit. These audits are reallowed by entering input messages ALW:AUD=SODD,FULL and ALW:AUD=SODD,INCR, respectively. To determine the current status of the audit, enter input message REPT:AUD=SODD. The status includes an indication of which audits are active, which entity is currently being audited, how far along the audits are, and so forth. Each audit execution concludes with a summary message indicating how many errors were detected. To obtain the contents of an existing error log generated by a previously executed full or incremental audit, enter input message OP:AUD=SODD,ERRLOG. After investigating the reported error, make any necessary data base corrections using RC (and ODBE when needed). Then request an entity audit to verify the corrections. Refer to AT&T 235-105-220, Corrective Maintenance Procedures, for detailed information on analyzing error reports and making data base corrections. The STP:AUD=SODD,FULL command stops the current execution of the full audit, and the STP:AUD=SODD,INCR command stops the current execution of the incremental audit. Properly formatted, the STP:AUD=SODD command stops execution of all (full, incremental, and entity) running audits. If multiple entity audits are running, each is stopped individually. If the STP:AUD=SODD,FULL command has been used, the EXC:AUD=SODD,FULL command can be used to restart the full audit (provided the schedule allows it). Otherwise, at the next scheduled time, the full audit will restart from where it left off. If the incremental audit is stopped, it does not restart until after the next backup is completed. Hence, some of the transactions from the first log file that were not audited may not get audited. If the STP:AUD=SODD,INCR command has been used, the EXC:AUD=SODD,INCR command may be used to restart the incremental audit before the next backup begins. The source and disassembly listing files of the system are contained in the PRs. The naming concept for PRs is defined as follows: o The complete name is in capital letters. o The first part of the name is the processor (SM/AM) on which the code is executed. o The second part of the name is the subsystem process/software module. o The two parts are divided by a colon ``:''. The following is an example of a PR name reflecting the guidelines defined previously (processor:subsystem product): SM:FCPOTS The PRs are available only in the form of microfiche. Therefore, the user must use a microfiche viewer to read the PRs. Remember, some users refer to microfiche as ``fiche''. The first page of the PR is the cover sheet containing the system name, PR name, PR descriptive title, software release issue, PR number, date of issue, page count, and the proprietary message. The PR document can be divided into the following seven sections: 1. Prologue (optional) 2. PR section index 3. Global header index 4. Local header files 5. Function index 6. Main body (source listing and disassemblies) 7. Epilogue (optional). If a prologue is provided, it can be used to supply a variety of information to the user (for example, instructions, program's functions). Remember, this section is optional. The Section Name appears in either the upper left-hand corner or in the center of the first page of each section. If presented in the left-hand corner, the section name appears directly below the PR name. The PR name appears on the upper left-hand corner of every page of the PR document. The PR title description (from the cover page) also appears in the lower left-hand corner of every page of the PR document. There is an exception to this rule, concerning the Main Body section where the function name (instead of the section name) appears in the upper left-hand corner of the first page of the function listing. The global header files contain definitions of program constants and data structures which may be shared. The global header file section follows the PR section index. It contains the names of all global header files referenced in the PR document and the PK document in which it is found. If no global header files are used within the program, the word ``NONE'' appears after the words ``GLOBAL HEADER FILES''. These declarations are declared by the ``include'' statement in the program where they are to be used. See the ``include'' statement that follows: !include <hdr/as/ASmacros.h> Symbols ``< >'' indicate a global header file named hdr/as/ASmacros.h. The ``#include'' gives the complete pathname of the file. It must be included as a part of each function in which it is to be used. All global header files are documented in the PK cross- reference indexes. These indexes are named: symbol address cross-reference index and function address PR name cross- reference index. These indexes are covered later in the section. Local header files contain private definitions and data structures for a particular program. Local header files appear after the last page of the global header file section. It defines all the local header files declared by the program as well as the listing of the sources for local headers. If no local header files are used in the program, the word ``NONE'' appears after the words ``LOCAL HEADER FILES:''. The local header files are defined in the local header section and are declared within the function where they are used. The declaration is performed with the ``#include'' statement. See the following example. include <fc/hdr/FC1st_stag.h> In this example, the ``< >'' indicates a local header file named fc/hdr/FC1st_stag.h.. The statement indicates this file is to be used as a part of the process in which it was declared. Remember, the complete pathname must be specified. Local header files are defined within the ``LOCAL HEADER FILES'' section of the program where they are used. o These files are arranged alphabetically by the local header filename within the specific section. o The name of each local header file appears in the upper left-hand corner, directly below the section name of each page on which it is documented. Global header files can be distinguished from local header files by the placement of the ``hdr'' directory in the pathname. When the ``hdr'' is the first directory in the path, the header file is global. When the ``hdr'' is the second directory in the pathname, the file is local. See the following example. HEADER FILES Global and Local Header File Differences Global - hdr/xxx/xxxxxx.h Local - xxx/hdr/xxxxxx.h The function index section provides an index to all of the functions that make up a particular PR. The functions are sorted by their assembly language starting address and function name within the PR. The index is presented in a 2-section format. The first section, Figure .AW G132/, is sorted by ``name'' and the second, Figure .AW G133/, by ``address.'' The first column indicates how the functions are sorted. o The name sort section shows the functions sorted alphabetically by name. The first column in this section lists the function name, the second column lists the starting address, and the third is the PR document page number. o The second section is sorted by starting address. The format for this section is the same as outlined previously, except the first and second columns are swapped. The main body contains the functions which make up the program. Each function has the ``C'' language source code listing in one section followed by the disassembled listing in the next section. o Functions are arranged numerically in the main body section by their physical address. o The function's name is listed at the top of the first page of each function description. Functions can be distinguished from macros by the name. A macro name can/may not be all capital letters, and a function has only the subsystem abbreviation capitalized. The remainder of the name is in lowercase letters. (See following examples.) Function FCdig_coll( ) Macro FCGETPORT( ) Disassembly statements associated with a function begin at the top of the next page after the last right-hand brace ``}'' of the source code listing for that function. The fields of the disassembly listing portion of the function (Figure .AW G134/) are as follows: o First field: LINE NUMBER -- The numbers in [n] brackets are break points (expand function). o Second field: LOCATION -- This field contains the hexadecimal address of the first byte of the instruction offset from the beginning of the memory block containing the function. o Third field: CONTENTS -- This field is made up of three subfields and contains the hexadecimal encoding of the instruction. All three subfields are not always used. o Fourth field: INSTRUCTION -- This field contains the instruction mnemonics. o Fifth field: INSTRUCTION OPERANDS -- This field contains the instruction labels or operands. Both the ``C'' language and the disassembly portions of a function have decimal numbers within [n] brackets. The numbers relate specific ``C'' source lines to their disassembled counterparts as follows: o Function line numbers always begin with number one [1] starting at the first left-hand brace ``{'' of the function. o Lines are numbered consecutively until the last right- hand brace ``}'' of the function. o The numbers within brackets [n] provide a convenient reference point between the ``C'' and disassembled code. Figures .AW G135/ and .AW G136/ illustrate a portion of both the ``C'' source and disassembled code for the function FCann_id of program SM:FCTN_ANN. The line numbers can be used to reference between the two listings as follows: o Line [5] of the ``C'' source code indicates a function call to PHrel passing the symbol FCPATHO as an argument. a. Within the disassembled listing line [5], the first statement is a move. b. The next instruction is move long (move L), c. Followed by a jump to subroutine (jsr), d. And finally an add long (add L). The epilogue is an optional section of the program record. When included, this section provides: o Printable data files used by the program o Explanatory comments. The PKs contain information on the global headers, symbol, function, address information, and PR cross-reference. The naming format for the PK documents is as follows: o Unlike the PRs, only part of the title is capitalized. o The first part of the name identifies the processor. This part is capitalized. o The second part of the name identifies the process_name. This part can be made up of partially capitalized letters or no capital letters at all. o The two parts are separated by a colon``:''. processor:process_name SM:FCimp The first page of the PK is the cover sheet. The global header information is defined in a set of PKs. The PK document is organized as follows: o Global Header PKs are presented alphabetically and numerically (for example, A through E is represented in PK-100). o SYMBOL ADDRESS CROSS-REFERENCE INDEX and the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX are provided for all products that can be updated by function replacement (for example, OKP and IM.out). Note: The SYMBOL ADDRESS CROSS-REFERENCE INDEX and the FUNCTION ADDRESS PR NAME CROSS- REFERENCE INDEX are orderable as a set of PKs (PK number is PK-5DXXXXX-YY). These indexes are reissued with every point load. All telephone companies on standing order for group 80 automatically receive these indexes. The header file section can be identified by locating the filenames listed at the far right portion of the second and third lines of the microfiche page header. These filenames are in alphabetical order. To find where the file is on the microfiche page, look at the page index area (G09 - lower right-hand display area -- see Figure .AW G137/). The header files can be identified as the files that end with ``.h''. From illustration shown in Figure .AW G137/, the first entry on Page 99 contains the information on the symbol tag (line P# 99/tag .... B06), and Page 100 starts the header file section with the file ASmacros.h in area C06. These header files define the symbols listed in the Global Header File External Symbol Table. The symbol address cross-reference section can be identified by looking at the microfiche page header and the index area (G09) for the filenames ending with M. See the illustration in Figure .AW G138/ for the example of the G09 symbol address cross-reference list. The program change (PC) documents for the 5ESS switch are issued with each consolidation load (that is, with each new software release). The PC document describes all changes applied by these software updates since the first issue of PRs and PKs. The PC document is intended to be used in conjunction with the PRs and PKs as a supplementary update. The PC document only contains 5ESS switch code changes and does not include any changes produced for the UNIX RTR computer system. The attributes of the PC document are as follows: o An index is supplied that is sorted by the software update number, and indicates associated PR number, PR name, changed function names, PC issue, and the section of the document where the function listing appears. o Contains all changed functions since the last release of the PR documentation. o The PC document is cumulative. Previous issues are contained in each release. o If more than one change affects the same function, only the most current copy of the function appears in the document. o The microfiche produced is based on an individual PR. One PR per page or pages of microfiche. o Global headers are not included in the PC document; however, their affect upon the functions are included by the listing and disassembly contained in the document. The PCs are issued for every point load (PC number is PC- 5DXXXXX-YY). Also, the telephone companies on standing order for PRs and PKs automatically receive the PCs. The SYMBOL ADDRESS CROSS-REFERENCE INDEX is a document that provides a way to convert an external symbol within a bound product to its starting address. The external symbols defined are functions, arrays, structures, and variables. The information is sorted two ways. The first sort is keyed by address (left two columns). The second sort is keyed by function (right two columns). The primary application of this document is for analysis of addresses printed on the ROP. For this application, the user scans the address sort looking for an address that is greater than the failing address. Once the address is found, the user must back up one entry to find the starting address of the symbol containing the desired address and the symbol's name. To determine the PR document that contains a function, refer to the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX. To determine the PR document that contains a symbol (that is, not a function), refer to the SYMBOL ADDRESS CROSS-REFERENCE INDEX. The address information contained in this document is correct for any office that applies the standard software updates. If a craft software update is applied, the address information can be skewed by the size of the function added in the CFT software update. If an entry in this document is in doubt, the definitive answer can always be obtained from the 5ESS switch. The UPD:FTRC command can provide this information. The FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX provides a way to convert an address within a bound product to the PR document that contains the source code of that address. The document defines all external functions within the bound product, their starting address, and the PR document that contains that specific function. The information is sorted three ways. The first sort is keyed by address (left three columns). The second sort is keyed by function (middle three columns). The third sort is keyed by PR name (right three columns). The primary application of the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX is for analysis of addresses printed on the ROP. For this application, the user scans the address sort looking for an address that is greater than the failing address. Once the address is found, the user must back up one entry to find the starting address of the function containing the desired address, the function's name, and the PR that contains the source for that specific function. The function index in the appropriate PR is consulted to determine which microfiche page contains the source code for the function being analyzed. The address information contained in this document is correct for any office that applies the standard software updates. If a craft software update is applied, the address information can be skewed by the size of the function added in the CFT software update. If an entry in this document is in doubt, the definitive answer can always be obtained from the 5ESS switch. The UPD:FTRC command can provide this information. The SYMBOL ADDRESS CROSS-REFERENCE and FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEXES, when used with the appropriate PR document, can guide a user from an address printed on the ROP to the associated source code. This guide is only applicable for addresses from OKP and IM.out. The address information assumes that no CFT software updates have been added to the switch. Figure .AW G139/ shows how the cross- reference indexes can be used. Note: This example pertains to IM.out, but the steps are the same for OKP. 1. An assert has occurred, and the associated stack information has printed on the ROP or has been retrieved from the DAYLOG. Review the first line of the assert message to determine the process that asserted (refer to the 21200 assert message display in Figure .AW G139/). The display shows OSDSM, which indicates the assert came from IM.out (line 1 on Figure .AW G139/). 2. Extract the list of processes that were on the stack by analyzing the USER stack (refer to line 8 of Figure .AW G139/ ``000CF6D2''). The USER stack defines all of the open function calls that existed at the time of the assert. An analysis of the actions performed by these functions provide details concerning the status of the process at the time of the assert. The address closest to the word ``USER'' (that is, 000CF6D2) is the most recent function. Other functions are represented in reverse chronological order, left to right. 3. To determine the function of an address on the USER stack, consult the SYMBOL ADDRESS CROSS-REFERENCE INDEX that is sorted by address. The list is analyzed until an address greater than the address in question is located. The function containing the address in question is the function previous to the address just located. Refer to the IM.out locations (by address) display shown in Figure .AW G140/ (address 0x000CF6D2 is between 0 x000cf548 and 0x000cf714). Note: The address in the SYMBOL ADDRESS CROSS- REFERENCE INDEX is the starting address of a function. The address in question is from the middle of a function. To locate a function, locate the starting address of the next function, then back up one entry. 4. Refer to the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX sorted by function for the appropriate product. Find the function located in the previous step. The number to the left of the function name is the PR number which contains the source code. Refer to the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX sorted by function name display shown in Figure .AW G141/ [look for PR name (that is, AM:IMFPUMP): DBstg2ex]. 5. Refer to the index page of the microfiche within the appropriate PR. Locate the page that contains the FUNCTION ADDRESS PR NAME CROSS-REFERENCE INDEX. Go to that page and look up the function name that had been previously found. This gives the microfiche page of the source code for the function. The TR303 IDCU remote terminal (RT) is available for 5E8 and later software releases. Provisioning of the TR303 RT is the process by which selected system parameters and end user subscription data are transferred from the 5ESS switch into a TR303 RT. This is done automatically by the switch whenever a change is detected in the switch's copy of the provisioned data. In order to maintain the integrity of provisioned data in the RT, the data is refreshed once daily. A failure reporting mechanism is provided to aid in troubleshooting provisioning problems and to offer a way to provision all or a subset of the data on demand. When a TR303 RT is ``grown in,'' field 164 in RC view 18.15 determines whether or not the switch is responsible for RT provisioning. If field 164 is set to N, the switch will not provision any data into the RT. It is assumed that some other Operations System (OS) provisions the RT with data consistent with the corresponding 5ESS switch line assignment data. If the field is set to Y, the switch is responsible for provisioning all global, DS1, and line assignment data into the RT. If field 164 in RC view 18.15 is updated from N to Y, then the input message EXC:RT,PROV,TYPE=ALL must be used to provision the RT. The 5ESS switch will not automatically provision the RT upon the commitment of the update. When the 5ESS switch data base is updated via RC or ODBE, an automatic provisioning operation is invoked if the changed data is also kept in the RT. This automatic provisioning operation collects the necessary data, formats it according to the TR303 interface specification, and sends it to the RT. If this operation is unsuccessful because of a transient problem [for example, embedded operations channel (EOC) is OOS, RT has resource limitations, switch is in an overload condition, etc.], the switch stops the current provisioning operation and tries again 15 minutes later. The provisioning operation is retried every 15 minutes until it is successful. If the provisioning operation is unsuccessful because of a nontransient type of error (for example, 5ESS switch data base corruption or RT responds with an unexpected failure to a provisioning request), the provisioning operation is aborted and is not subject to the 15-minute retry scheme. Nontransient types of failures are reported to the ROP if provisioning reporting is enabled. In addition to data base updates, there are several other stimuli that cause the switch to provision selected parameters into the RT. These include but are not limited to the following: o EOC Recovery from Duplex Fail: All global and DS1 parameters are provisioned when the RT's EOC channels are restored from a duplex fail state. o System Clock Change: When the system clock changes for any reason, the new local time is provisioned into the RT. o RT Provisioning Request: When the RT requests to be reprovisioned via a memory corruption alarm, the switch provisions all of the data into the RT. In order to maintain the integrity of provisioned data in the RT, a routine provisioning operation begins 15 minutes after midnight in every SM that has a TR303 remote terminal assigned. The routine provisioning operation sequentially steps through all TR303 RTs on the SM and refreshes system- level parameters per DS1 and line parameters. Provisioning status messages and individual failure messages are sent to the ROP during this operation if provisioning reporting is enabled. The failure report is available to report provisioning failures to the ROP. The failure report shows the operation that was attempted as well as the specific reason for the failure. Reporting can be enabled/disabled on a per-SM as well as a per-RT basis. The default state for reporting is disabled. Failure reporting must specifically be enabled via input message ALW:RT,PROV,REPT. The INH:RT,PROV,REPT command is used to disable reporting. The OP:RT,PROV input message is used to get the current reporting state for a given RT. Refer to AT&T 235-600-700, Input Messages Manual, for information on the use of these commands. If for some reason it is believed that the provisioned data is out of sync with the switch data, an input message is available to cause the switch to refresh on demand, either a subset or all of the data in the RT. The EXC:RT,PROV input message causes the switch to immediately try to provision the selected data and report the results. The argument (TYPE=a) used in the input message specifies the subset of data to be provisioned. Arguments are as follows: o ALL: All provisioned data is refreshed. An RT identifier must be provided. o GLOBAL: Only RT global and DS1-related data is refreshed. An RT identifier must be provided. o IFAC: Only DS1-related data is refreshed. An RT identifier must be provided. o LINE: Only data for a single line is refreshed. A line identifier must be provided. Refer to AT&T 235-600-700, Input Messages Manual, for details. When the RT sends a ``memory corruption'' alarm to the switch, the switch reprovisions the RT immediately. This should be a rare event, caused by a field technician clearing the RT's memory. The other RT alarm that affects provisioning is a ``memory mismatch'' alarm. This is an indication of an internal RT memory failure which cannot be cleared automatically. While in this state, it is unlikely that any provisioning operations would be successful. Therefore, all provisioning operations are inhibited for that RT while it has an active ``memory mismatch'' alarm. The OP:RT,PROV input message described previously also retrieves this inhibit status. When the alarm is cleared via a ``memory mismatch clear'' indication from the RT, the inhibit is removed. However, this is not an indication to reprovision the RT. Any service order changes that are processed while in the ``memory mismatch'' alarm state results in the provisioning operations being deferred. These operations should begin within 15 minutes of the alarm being cleared. When a TR303 line is assigned, it is placed in the Circuit Administration - Provisioning state (OOS CADN DSBLD PROV). It remains in this state until the line parameters are successfully provisioned into the RT. Since provisioning is normally done immediately following line assignment, the line should only be in this state for a few seconds. However, if the EOC is OOS or if the RT responds to the provisioning request with an error, the line may stay in the CADN state until the error condition is cleared. The OP:LIST,LINES,CADN input message can be used to find lines stuck in the CADN state, an indication of potential provisioning problems. Some TR303 channel units that the switch does not know how to provision are used for nailups/hairpins. These ``specials'' are either provisioned locally or provisioned remotely through an OS that communicates directly with the RT. To avoid having the switch overwrite this data with its own subscription data, a field in RC view 1.6 is used to mark lines so that provisioning knows not to touch these specific line terminations. Field ``TR303 NAILUP'' is added to the analog line assignment RC view 1.6 to indicate whether or not the switch is responsible for provisioning this line. If the field is set to Y, the switch will not provision the line termination data for this line, and the line can only be used for a nailup/hairpin. If the field is set to N, the switch provisions the line termination data for this line. In either case, Y or N, the switch provisions the time slot cross-connection data provided in the nailup/hairpin view (RC view 7.11). See AT&T 235-105-220, Corrective Maintenance Procedures, and AT&T 235-105-210, Routine Operations and Maintenance Procedures, for TR303 RT provisioning procedures. This section contains the Introduction to MCC Pages subsection and the MCC Page Displays subsections for 5E6 and later software releases. Note: Product rating for the 5E2(2), 5E3, 5E4, and 5E5 software releases has been changed to Discontinued Availability (DA). Effective with Issue 7.00 of this document, all MCC page displays valid for 5E6 (or 5E6 and later) previously included in subsections for software releases rated DA have been moved to the 5E6 subsection. This section provides detailed descriptions of the page displays of the 5ESS(R) switch master control center (MCC) video terminal. Only the maintenance displays are covered in this document. The following page displays are either not covered in this section or not covered in this manual: o EMERGENCY ACTION PAGE: Information on the emergency action interface (EAI) page can be found in Section .RM 3.2.4/ of this manual. o 124 - GENERIC RETROFIT: The GENERIC RETROFIT page and its two argument pages (ARGSPG1 and ARGSPG2) provide commands to perform Software Release Retrofit, Software Release Update, and Large Terminal Growth (LTG) transitions on the night of retrofit. The 124 page also shows the status of the transitions and displays error messages when abnormal conditions occur. The 124 page should be used only during software release transitions. Refer to the following manuals for a detailed description of the GENERIC RETROFIT page and procedures for its use: -- AT&T 235-105-24X, Software Release Retrofit Procedures -- AT&T 235-105-34X, Software Release Update Procedures -- AT&T 235-105-44X, Large Terminal Growth Procedures. o 16X, 160,Z, and 161,X - TRUNK AND LINE MAINTENANCE: Information on the TLWS, a subsystem of the MCC, can be found in Section .RM 3.4/ of this manual. o 193 - VERIFY TEXT: Information on the VFYTXT page can be found in Section 5 of AT&T 235-105-210, Routine Operations and Maintenance Procedures. o 194 - SCREEN PROGRAM USER'S GUIDE: Information on the Screen Program User's Guide can be found in Section .RM 3.11/ of this manual. o 195 - GENERIC BACKUP: Information on the GENBACKUP page can be found in Sections 4 and 5 of AT&T 235-105-210, Routine Operations and Maintenance Procedures; Section 4 contains descriptive information on generic backup of disks and tapes, and Section 5 contains procedures. o 196 - ODD RC/V: Information on office dependent data (ODD) can be found in AT&T 235-600-100, Translations Data Manual. Also, all recent change/verify (RC/V) views are described in AT&T 235-118-2XX (XX = manual number associated to the applicable software release), Recent Change Procedural Manuals. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of RC/V manuals. o 198 - SG RC/V and 199 - ECD RC/V: Information on equipment configuration data/system generation (ECD/SG) RC/V can be found in AT&T 235-600-30X (X = manual number associated to the applicable software release), ECD/SG Data Base Manual. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of ECD/SG manuals. The following information is provided for each page display covered in this section: 1. Statement of purpose. 2. General information about the display, including the chain of events in the hierarchy generated by off-normal conditions, if applicable. 3. Detailed descriptions of complex or unusual indicators. 4. Illustration of the display with an explanation of abbreviations used. 5. Maintenance menu commands available from the display, including any available options which are shown in brackets, such as [,UCL] (unconditional). Table .AW TAF/, MCC Page Location Guide, can be used for locating information on specific MCC pages for specific 5E6 and later software releases. All MCC page displays included in this document are listed in the page location guide in numerical order by page poke number. General The following describes several sections that comprise each page display (Figure .AW G142/). Office Data (Line 1) The top line contains the office name and type (from the equipment configuration data base), the software release and issue, terminal ID, the current date, and a 24-hour clock. This information is present on all MCC displays. Summary Status Area (Lines 2 and 3) Lines 2 and 3 contain the SUMMARY STATUS indicators, which are present on all MCC displays. These indicators provide summary status of hardware units and software actions in the system. The first indicator, SYS EMER (system emergency), flashes when the AM loses sanity. The craft should use the EAI (emergency action interface) display if this occurs, which is obtained by depressing the EA DISP function key on the auxiliary keypad of the MCC. The next three indicators, CRITICAL, MAJOR, and MINOR, are used to show the level of an alarm. When an alarm occurs, the indicator for the alarm (for example, BLDG/PWR) starts flashing. At the same time, the alarm level indicator backlights to show the level, but does not flash. When an alarm is retired, the alarm-level indicator returns to normal video; the alarm indicator stops flashing, but still remains backlighted. The eighth indicator, SYS NORM (system normal), is backlighted when there are no off-normal conditions in the system. There is a direct correlation between the other indicators and the associated display page number. For example, the associated page display for the tenth indicator, SYS INH (system inhibits), is 110 - SYSTEM INHIBITS. Information on the other indicators is provided in the descriptions of the associated page displays. Command and Page Identifier The fourth line has five sections. When the MCC is in the command mode, CMD appears at the left-hand margin and the cursor is positioned immediately after it for command input. Following the command input area is an acknowledgment area. The acknowledgments that appear here only show whether the input command is valid. The next area is used to give execution status of the request. The last area on this line contains the page number and title; if not, enter 100 for page index. Display Region Lines 5 through 22 usually contain the text and graphics for the display. There are exceptions to this rule. For example, displaying 120 - MESSAGES page allows input and output messages to scroll into this region. Maintenance and paging commands, if any, are usually along the left-hand margin. On a few displays, they are across the top because of space restrictions. The first digit of the maintenance commands implies the action to be taken, as follows: First Digit of Command Type of Action 1 Display a page 2 Remove a unit from service 3 Restore a unit to service 4 Switch units or set software control 5 Diagnose a unit or clear software control 6 Inhibit software control 7 Allow software control 8 Control/display commands 9 Output or initialization control Input/Output Message Region Line 23 to the bottom of the screen is a normal input/output message region. Input messages are entered from the bottom line. Input and output messages scroll up from the bottom line of this region. A 5ESS switch office can be supplied with an MCC video terminal that has a black and white display or an optional 5-color (plus black and white) display. The most commonly used states in the 5ESS switch and their video characteristics are listed in Table .AW TAG/. Black and White Terminals On black and white terminals, the general guidelines used in selecting the states are as follows: o White on black: Normal conditions (for example, active or unequipped) o Black on white (reverse video): Off-normal conditions and acknowledged alarms (for example, out of service or unavailable) o Flashing black on white: Unacknowledged alarms and severe off-normal conditions (for example, critical major and minor alarms in the summary status area, a fire alarm or isolated SM). Color Terminals For color terminals, the guidelines used are as follows: o White on black: Normal conditions (for summary or informational indicators) o Green background: Used for active or predominately active units o Cyan background: Off-normal unalarmed conditions (for summary indicators) o White background: Minor acknowledged alarms, low-severity off-normal conditions, and standby units o Yellow background: Major acknowledged alarms and medium- severity off-normal conditions o Red background: Critical acknowledged alarms and high- severity off-normal conditions o Flashing: Unacknowledged alarms and extremely severe off- normal conditions. This subsection contains the master control center (MCC) page displays and their descriptions that are effective with or changed with the 5E6 software release. In addition, product rating for the 5E2(2), 5E3, 5E4, and 5E5 software releases has been changed to Discontinued Availability (DA). All MCC page displays valid for 5E6 (or 5E6 and later) previously included in those subsections were moved to the 5E6 subsection. Refer to Table .AW TAF/ for a complete listing of MCC page displays. The purpose of the SSA page is to provide the summary status of hardware units and software actions in the system. The first indicator, system emergency (SYS EMER), flashes when the AM loses sanity or when the system initializes. Under either of these conditions, the craft should use the Emergency Action Interface (EAI) display. The Emergency Action Interface can be accessed by depressing the EA DISP function key on the auxiliary keypad of the master control center (MCC). The next three indicators, CRITICAL, MAJOR, and MINOR are used to show the level of an alarm. When an alarm occurs, the indicator for the alarm (for example, BLDG/PWR) starts flashing. At the same time, CRITICAL, MAJOR, or MINOR will backlight to show the level, but these indicators do not flash. When an alarm is retired, the CRITICAL, MAJOR, or MINOR indicators will return to normal video; the alarm indicator will stop flashing but will still be backlighted in the color of the alarm level. When the appropriate MCC page is displayed (for example, 105 for BLDG/PWR), the alarm indicator will backlight in cyan. The fifth and sixth indicators, BLDG/PWR and BLDG INH are driven by the combined Page 105/106 (see Figure .AW G145/). Notice the direct correlation between the indicator position and the associated display page number. For CKT LIM, see MCC Page 107 - CIRCUIT LIMIT (Figure .AW G146/). The system normal (SYS NORM) indicator is backlighted when there are no off-normal conditions in the system. For Overload, see MCC Page 109 - Overload (Figures .AW G147/ and .AW G148/). For SYS INH, see MCC Page 110 - System Inhibit (Figure .AW G149/). For AM and AM PERPH, see MCC Page 111/112 - AM, AM Peripherals (Figure .AW G150/). For OS Links, see MCC Page 113 - Operations Systems Links (Figure .AW G151/). For SM, see MCC Page 114 - Equipped SM Status Summary (Figure .AW G152/). For CM, see MCC Page 115 - CM Summary (Figures .AW G153/ and .AW G154/). For MISC, see MCC Page 116 - Miscellaneous (Figure .AW G155/). Figure .AW G143/ shows the SUMMARY STATUS AREA. These system indicators are presented on all MCC displays. In this example, there are no off-normal conditions, which is shown by the SYS NORM indicator. The purpose of the 100 Page Index is to provide an index of main system pages. This index is a listing of primary maintenance displays and is also an entry point into other subsystem displays, such as trunk and line maintenance, equipment configuration data (ECD), and office dependent data recent change and verify (ODD RC/V). The per-switching module (SM) pages are not shown on this display. The SMs have their own index (1000 - SM PAGE INDEX). There is a direct correlation between the page numbers of Pages 105 through 116 (except 108) and the physical position of the status summary indicators in the SUMMARY STATUS AREA. For example, the fifth status summary indicator in the SUMMARY STATUS AREA (from left to right) is BLDG/PWR. Its associated display is 105 - BLDG/PWR & ALARM CONTROLS. Some of the status summary indicators do not have an associated display page. These are listed on the index as ``NOT ASSIGNED.'' This is a built-in trouble-locating shortcut. The page number for an alarm can be derived from the alarmed indicator's position without going to this display, although this display is always available. Information on ODD can be found in AT&T 235-600-104, Translations Data Manual. Also, all RC/V views are described in AT&T 235-118-2XX (XX = manual number associated to the applicable software release), Recent Change Procedural Manuals. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of RC/V manuals. Information on equipment configuration data/system generation (ECD/SG) RC/V can be found in AT&T 235-600-30X (X = manual number associated to the applicable software release), ECD/SG Data Base Manual. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of ECD/SG manuals. Pages 196, 198, and 199 (RC/V pages) do not appear when the 100 Page Index page is displayed at the switching control center (SCC) because the RC/V pages cannot be displayed at that location. Pages 118 (CNI STATUS) and 1211 (NETWORK CLOCK) are shown depending on switch configuration. Figure .AW G144/ shows an example of the 100 Page Index. The commands on this page can be entered from any display page, under normal operation. Also, any available per-SM display can be accessed. See 1000 - SM PAGE INDEX (Figure .AW G196/) for details. 2 CMD RESULT 100 PAGE INDEX is displayed 105/106 BUILDING/POWER AND ALARM CONTROLS page is displayed 107 CIRCUIT LIMIT page is displayed 109 OVERLOAD page is displayed 110 SYSTEM INHIBITS page is displayed 111/112 AM, AM PERIPHERALS page is displayed 113 OPERATIONS SYSTEMS LINKS page is displayed 114 EQUIPPED SM STATUS SUMMARY page is displayed 115 COMMUNICATION MODULE SUMMARY page is displayed 116 MISCELLANEOUS page is displayed 117 IOP APPLICATION PROCESSOR DATA LINKS page is displayed 118 COMMON NETWORK INTERFACE FRAME AND COMMON CHANNEL SIGNALING LINK STATUS page is displayed 119 MISCELLANEOUS ALARMS page is displayed 120 MESSAGES page is displayed 121 IOP 0 & 1 page is displayed 122 IOP 2 & 3 page is displayed 123 DISK FILE SYSTEM ACCESS DFC 0-1 page is displayed 124 GENERIC RETROFIT page is displayed 125 DISK FILE SYSTEM ACCESS DFC 2-3 page is displayed 126 DFSA PERFORMANCE DFC 0-1 page is displayed 127 MTIB page is displayed 128 DFSA PERFORMANCE DFC 2-3 page is displayed 129 DEFENSE SERVICES NETWORK NM EXCEPTION page is displayed 130 NM EXCEPTION page is displayed 131 CALL TRACE MENU page is displayed 160 TRUNK AND LINE MAINTENANCE INDEX is displayed 178 AUTO SPARE DISK page is displayed 179 DISK CONFIGURATION page is displayed 180 DISK CONFIGURATION page is displayed 181 OFFLINE SM 1-48 STATUS SUMMARY page is displayed 182 OFFLINE SM 49-96 STATUS SUMMARY page is displayed 183 OFFLINE SM 97-144 STATUS SUMMARY page is displayed 184 OFFLINE SM 145-192 STATUS SUMMARY page is displayed 190 C/D UPDATE page is displayed 191 OS STATUS page is displayed 193 VERIFY TEXT page is displayed 194 SCREEN page is displayed 195 GENBACKUP page is displayed 196 ODD RC/V is started. NOT FOR USE FROM SCC 197 CUTOVER page is displayed 198 SG RC/V is started. NOT FOR USE FROM SCC 199 ECD RC/V is started. NOT FOR USE FROM SCC 1000 SM PAGE INDEX page is displayed 1209 ONTC 0 & 1 page is displayed 1210 MI/NC 0 & 1 page is displayed 1211 NETWORK CLOCK page is displayed 1220 TMS 0 & 1 SUMMARY page is displayed 1240 MSGS 0 SUMMARY page is displayed 1250 MSGS 1 SUMMARY page is displayed 1260 CLNK SUMMARY page is displayed 1271 REX STATUS page is displayed 1850 CMP INHIBIT AND RECOVERY CONTROL page is displayed 1940 EASY BWM INSTALLATION page is displayed 1950 PROGRAM UPDATE MAINTENANCE MENU page is displayed 1960 BWM INSTALLATION page is displayed 1999 STATE DEFINITIONS page is displayed The purpose of the 105/106 display page is to summarize building/power alarm status and assignment, to provide inhibit/allow controls for building alarms, and to provide controls for alarm retire mode. Building Alarms 02-27 and their alarm levels are office assignable. Doors, windows, humidity, etc., are typical types of applications. The alarm level and text in these indicators are initially filled in using a TTY input message. [CHG:ALM,BPSC=building alarm number (2 through 27), TAG=text to be filled in, LVL=CR, MJ, MN, or IF.] Once these indicators are filled in, they are protected from loss if the system is booted. When an alarm indicator is normal, it is displayed in normal video (white on black). When an alarm condition is present and it is not inhibited, the respective display indicator will backlight, except for the FIRE indicator. The FIRE indicator flashes in addition to the backlighting. In the SUMMARY STATUS AREA, the associated alarm level (CRITICAL, MAJOR, or MINOR) will backlight, and BLDG/PWR will start flashing. Also, an audible alarm will be sounded. When an alarm is inhibited, the respective indicator will have "INH" written in and will be backlighted; BLDG INH in the SUMMARY STATUS AREA will also backlight. The 105/106 Page is accessed by either 105 which maps to the fifth critical indicator (BLDG/PWR) of the SUMMARY STATUS AREA, or 106 which maps to the sixth critical indicator (BLDG INH). Building alarms 02-27 are the only alarms on this page which can be inhibited by the craft. Any other inhibit present would be the result of a system inhibit. The indicator near the top right-hand portion of the display shows the retire mode (MANUAL or AUTOMATIC). Manual mode requires craft action (depressing the alarm retire key on the MCC) to stop CRITICAL and MAJOR alarms from flashing and to shut off the audible alarms. Automatic mode shuts off the audible alarms after 5 seconds. Figure .AW G145/ is an example of the 105/106 display page which shows off-normal building and power conditions. The indicator PDF FUSE shows a system inhibit. Indicator 05 shows a major alarm caused by a failure in the air-conditioning system. Indicator 09 shows the door is inhibited from triggering a building alarm. The office is in the automatic retire mode, as shown in the top right-hand area of the display. Commands are provided to select retire mode and to inhibit/allow building alarms 02-27. Also, all available pages can be accessed from the 105/106 display page. CMD RESULT 6XX Building Alarm XX is inhibited (INH:ALM,BPSC=XX) 7XX Building Alarm XX is allowed (ALW:ALM,BPSC=XX) 800 Automatic Alarm Retire Mode is enabled (SET:ALMMDE=AUTO) 801 Manual Alarm Retire Mode is enabled (SET:ALMMDE=MAN) The 107 display page provides a listing of trunk groups that have exceeded their automatic maintenance limit (AML). If all the trunk groups are normal, no trunk group numbers are shown on the display. When a trunk group's automatic maintenance limit is exceeded, the trunk group number is listed. In the SUMMARY STATUS AREA, the CKT LIM indicator will be backlighted and flashing. The associated alarm level (CRITICAL, MAJOR, or MINOR), will also be backlighted, as applicable. This display lists the trunk group number(s) of the first 20 trunk groups out of service, in numeric order. When more than 20 trunk groups are out of service, the word "EXCESSIVE" will be backlighted at the bottom of the listing. Entering the output list command will give a complete listing of all out-of-service trunks at the receive-only printer (ROP). Figure .AW G146/ is an example of the 107 display page which shows an excessive amount of trunk groups out of service. The command 900 could be entered to get a complete listing. A command is provided to output the complete list of out-of- service trunk groups. All available paging commands can be entered from this display. CMD RESULT 900 Trunk Group Circuit Limit Listing is printed at the ROP (OP:AML) [,TG=a] where a is a specific trunk group number The 109 display page provides an indication of resource or real-time overloads in the administrative module (AM), communication module processor (CMP), and SM(s), and it provides commands to inhibit or allow essential service protection (ESP). Any AM, SM, or CMP overload conditions are shown on the 109 display page. The SM and CMP overload information is provided on a summary basis. If an SM overload occurs, the SM number and type will be displayed in the indicator and backlighted. If more than 16 SMs are in overload, a note will appear, partially backlighted, indicating how many SMs are overloaded. For a complete list of SMs in overload, the 900 command should be entered. If a CMP overload occurs, the CMP number and whether it is the primary (P) or mate (M) is shown. Details on an SM overload can be obtained by entering the DISPLAY SM X OVERLOAD INFO command shown on the display. Likewise, details on an overloaded CMP can be obtained by entering the DISPLAY PRIM CMP X OVERLOAD INFO or DISPLAY MATE CMP X OVERLOAD INFO. The REALTIME overload indicators will contain NONE, MINOR, MAJOR, or CRIT (critical) to show the severity of the overload. NONE means no overload exists. MINOR and MAJOR are different levels of real-time overloads. CRIT is only used for SMs and is the most severe type of overload. The only craft action which can be taken during overload conditions is to reduce or eliminate input messages/maintenance commands. All other actions are initiated by the system. For RESOURCE overloads, either NONE or the name of the resource will be displayed. The monitored resources are as follows: o MCB - Message Control Block o PCB - Process Control Block o RCV - Tone Receivers (SM only) o SCB - Stack Control Block o TCB - Timer Control Block o PKB - Packet Buffers [operator services position system (OSPS) SMs only] o PSU - Packet Switch Unit (Packet Switching SMs only) o ADB - Analog Data Block (SM only) o APB - Associated Process Block (SM only) o BRCSDB - Business and Residence Custom Services (BRCS) Data Block (SM only) o CBDB - Call Buildup Data Block (SM only) o CCBCOM - Channel Control Block (SM only) o CHDB - Channel Data Block (SM only) o CLDB - Calling Leg Data Block (SM only) o DALB - D-Channel Application Linkage Block (SM only) o DIB - Data Interface Block (SM only) o DISPDB - Display Data Block (SM only) o MDB - Model Data Block (SM only) o MSG - Message Overflow (because of PIC overload) o PHDB - Path Data Block (SM only) o SCMDB - Shared Call Model Data Block (SM only) o TSDB - Time Slot Data Block (SM only) o PSIB - X-25 Packet Input Buffer (SM only) o IAQ - CMP Input Queue (CMP only). Essential Service Protection is normally inhibited. Therefore, the INHIBITED text is not backlighted. When allowed, it gives preferential treatment to designated lines (for example, hospitals, police, fire departments, etc.) during periods of overload. If there is a network management control on to prevent overloads in this office, the ``SEE PAGE 130'' indicator will show up and be backlighted. An overload will cause the OVERLOAD indicator at the top of the screen to backlight. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. Figure .AW G147/ shows an example of the 109 display page with specific AM overload information. It also shows up to 16 of the SMs and up to 8 of the CMPs that are in overload. The note EXCESSIVE is displayed and backlighted because there are greater than 16 SMs in overload. The actual number of SMs in overload (20) is displayed. The AM information box contains information regarding real-time and resource overloads in the AM. The information provided on Page 109 for the SMs is the SM number and type. For additional information on a specific SM, the poke 1300,X is used (where X is the number of the SM). Similar to the SM, the CMP has limited information provided on Page 109 as shown in Figure .AW G148/. The information shown is the number of the CMP and whether the CMP is the primary or the mate. For more specific information regarding a specific CMP, the pokes 1370,X for the primary CMP and 1371,X for the mate CMP (where X is the number of the CMP) are used. Commands are provided to inhibit and allow ESP, to output a list of all SMs that are overloaded, and to obtain detailed information on an SM overload condition. In addition to these commands, any available paging command can be entered from Display Page 109. CMD RESULT 600 Essential Service Protection is inhibited (INH:ESP) 700 Essential Service Protection is allowed (ALW:ESP) 900 Output list of SMs in overload on the ROP (OP:OVRLD:ALL) 1300,X SM X Overload Information is displayed 1370,X Primary CMP X overload information is displayed 1371,X Mate CMP X overload information is displayed The 110 display page provides a list of system and AM inhibits and provides maintenance menu commands for selected inhibits. A SYSTEM inhibit applies to the AM and all SMs. An AM inhibit applies only to the AM. Unless stated otherwise, all inhibit requests are assumed to be phase-protected. Each inhibit indicator on this display has three distinct sections: the top line, the description, and the commands- available line. The top line in each box shows the box number. This line is displayed in normal video, and the field to the right of the box number is blank unless an inhibit has been requested by the craft. If an inhibit has been requested, INH, SET, MON, or CHG is displayed to the right of the box number, as appropriate, and the top line is backlighted. (For the remainder of the 110 display page description, the result of any of these operations is referred to as an inhibit.) The presence of this text and backlighting combination means the system has recorded the inhibit request. It does not mean the inhibit is in effect. Most of the inhibit/allow and set/clear commands are effective immediately after the request. For these cases, all areas of the indicator backlight together and one of the 3-character phrases (INH, SET, MON, or CHG) will appear. However, in a few cases, the status will change independent of the request. An example of this is shown in box 21. The behavior of each indicator is explained in the Indicators section on the next several pages. The middle two lines of the indicator is the inhibit description. These two lines show the name of the inhibit as well as whether or not an inhibit is in effect. Inhibits can be caused by system or craft-initiated actions. When an inhibit is in effect, this section will be backlighted. In the SUMMARY STATUS AREA, the SYS INH indicator will be backlighted. The return of the top line to normal video means that a valid request to allow (or clear) an inhibit has been accepted. A valid allow request will also cause any text in the area to the right of the box number to be blanked. The last line of each indicator shows which menu commands, if any, are available from the display. For example, at the bottom of box 17 the numbers ``6 7 9'' appear. The ``6'' means this item can be inhibited by entering 617, the ``7'' means it can be allowed by entering 717, and the ``9'' designates output is available with 917. On color MCCs, there is also color mapping from the commands shown on the left of the display to the numbers in the boxes. Boxes without commands listed are inhibited only by the system or from manual action independent of this display page. Following is the correspondence between the number key and the action taken: Number Action 4 Set 5 Clear 6 Inhibit 7 Allow 9 Output This paragraph describes the individual indicators and their behavior. Box 00 - Box 00 is not currently used. Box 01 - Message Class Brevity Control This indicator shows whether or not the automatic output message class brevity control is inhibited. Brevity control is used to restrict the generation of certain application output messages for both the AM and equipped SMs. Inhibiting message class brevity control permits normally suppressed messages to go to the ROP or the log file. The message class brevity control inhibit must be entered with the TTY input message INH:BREVC,MSGCLS=a. Since a named MSGCLS is required, a menu command is not provided. Inhibiting brevity control for one or more MSGCLSs may cause increased communication link traffic which can degrade call processing performance and capacity. (See AT&T 235-600-700, Input Messages Manual.) The request will display INH when recorded. This inhibit will take effect immediately with the request. Entering allow command 701 generates the message ALW:BREVC,MSGCLS=ALL. The request will clear the text INH when recorded. This allow will take effect immediately with the request. This inhibit is cleared by any high-level AM initialization. Box 02 - Message Class Log/Print Status The box 02 indicates that at least one message class has the log/print status that is different from the backup status. To change the log/print status for one or all message classes, enter input message CHG:LPS,MSGCLS={a|ALL} with additional parameters. (See the AT&T 235-600-700, Input Messages Manual.) The request will display CHG when recorded. This change will take effect immediately with the request. Entering the menu command 902 generates the input message OP:LPS,MSGCLS=ALL and causes the status of the message classes to be printed at the ROP. Box 03 - MDII Reporting The machine-detected interoffice irregularity (MDII) indicator is backlighted when one or more MDIIs are inhibited. The inhibits are generated by the TTY input message INH:MDII with additional parameters. When the inhibit is invoked, it suppresses the printing of MDIIs for the trunk group(s) specified by the input message. The request will display INH when recorded. This inhibit will take effect immediately with the request. Entering the 903 command generates the message OP:MDII, which causes a listing of all suppressed trunk MDIIs to be printed at the ROP. Box 04 - Manual Recent Change This indicator shows whether or not manual entering of recent changes is inhibited. When the command 604 is entered, the message INH:RC is generated. The request will display INH when recorded. This inhibit will take effect immediately with the request. The allow command 704 generates the message ALW:RC. The request will clear the text INH when recorded. Since the Automatic Customer Station Rearrangement (ACSR) feature depends upon Recent Change, if Recent Change is inhibited, ACSR is also inhibited. During manual inhibits of Recent Change, the RC box (box 04) is illuminated and the customer-originated recent changes (CORC) box (box 05) is partially illuminated. Box 05 - Customer-Originated Recent Change The box 05 indicator shows whether CORC are inhibited. Box 05 is shared by CORCs and the ACSR feature. Since the ACSR feature depends upon Recent Change, if Recent Change is inhibited, ACSR is also inhibited. During manual inhibits of Recent Change, the RC box (box 04) is illuminated and the CORC box (box 05) is partially illuminated. When a 905 command is entered, ACSR queuing is inhibited and CORCs are allowed. Box 06 - Recent Change Logging The box 06 indicator shows whether or not the logging of manually entered recent changes for all processors is inhibited. This does not include customer-originated recent changes. Recent Change logging may be inhibited in the event logging is causing a problem, thereby allowing recent changes to be entered. Unlogged changes are lost after a boot. Entering the command 606 generates the message INH:RCLOG. The request will display INH when recorded. This inhibit will take effect immediately with the request. Entering the command 706 generates the message ALW:RCLOG. The request will clear the text INH when recorded. Box 07 - Box 7 is not currently used. Box 08 - Communication Link Normalization If a fault occurs in one or more SM communication links, the system will automatically try to restore the link(s) on a periodic basis. This inhibit will suppress this action when active. Entering command 608 will generate the message INH:CLNORM. The request will display INH when recorded. This inhibit will take effect immediately with the request. When the command 708 is entered, it generates the message ALW:CLNORM. The request will clear the text INH when recorded. Since attempts to restore CLNKS are periodic, there may be a delay from the time an allow or inhibit request is recorded until the allow or inhibit is recognized. Box 09 - Centralized Automatic Message Accounting (CAMA) Suspension The box 09 indicator shows whether or not calls are being routed through the CAMA operator number identification (ONI) process for billing. Since inhibiting this indicator causes lost revenue, a minor alarm is sounded when the inhibit is invoked. Entering the command 609 generates the message INH:CAMAONI. The request will display INH when recorded. This inhibit will take effect immediately with the request. Entering the command 709 generates the message ALW:CAMAONI. The request will clear the text INH when recorded. Box 10 - Trunk Hold The box 10 indicator shows whether or not one or more trunk groups are being monitored. To monitor one or more trunk groups, the input message MON:TRUNK must be entered. The request will display MON when recorded. This monitoring will take effect immediately with the request. The system looks for stop-go signaling failures in members of monitored group(s). If a failure occurs, the member is held off-hook and out of service for the craft to determine the nature of the failure. The input message CLR:TRUNK is entered to remove the stop-go signaling. Warning: This message will return all members back to service, even if they failed. The request will clear the text MON when recorded. Entering the 910 command generates the input message OP:TRUNK, which causes a listing of all trunk groups and members being monitored to be printed at the ROP. Boxes 11 Through 15 - Boxes 11 through 15 are not currently used. Box 16 - Routine Audits The box 16 indicator shows if the automatic routine execution of one or both AM application audit cycles (OKP or SMKP) are inhibited. The only way to obtain a single audit inhibit is via a TTY input message in the message mode. (See INH:AUD=a,ENV=b in AT&T 235- 600-700, Input Messages Manual.) Single inhibits are not phase- protected. Entering the 616 command requests the inhibit of all audits and generates the message INH:AUD=CYCLE,ENV. The request will display INH when recorded. The request state does not necessarily imply that the inhibit is in effect. Normally, the status will follow the request within a short period of time. If the 716 command is entered, the message ALW:AUD=CYCLE,ENV is sent. The request will clear the text INH when recorded. The request state does not necessarily imply that the inhibit has been cleared. Normally, the status will follow the request within a short period of time. The command 916 (OP:AUD,STATUS=ALL,ENV=a) can be entered to get a ROP listing of routine audit status for the application AM. Box 17 - Routine Exercises The box 17 indicator shows if any or all of the application routine hardware exercises are inhibited in the communications module (CM). Inhibits for routine exercises are effective for only one exercise session. If the tests are in progress when the message is received, the inhibit will not take place until the next session. Routine exercises are scheduled to run at specific times (for example, daily at midnight). If inhibited exercises are allowed after the scheduled time, the exercises are not started until the next scheduled session. When 617 is entered, the message INH:REX,CM is generated, which inhibits all application CM routine exercises. The request will display INH when recorded. This inhibit will take effect immediately with the request. If the command 717 is entered, the message ALW:REX,CM is generated, which allows all application CM routine exercises. The request will clear the text INH when recorded. Entering the command 917 sends the message OP:REXINH,CM, which generates a status listing at the ROP. Note: These are application routine exercises and are different from the routine exercises for the AM, as shown on the EAI display. Box 18 - Software Checks The box 18 indicator reflects whether or not the AM application software checks have been inhibited. The AM software checks and the application software checks are different, but are controlled together from manual commands. The box 18 indicator can only be controlled from the EAI or TTY input message INH:SFTCHK. This inhibit will prevent internal software checks from causing initializations. The request will display INH when recorded. If the status is inhibited without being requested, the inhibit was automatically applied by the system. A request to allow software checks, ALW:SFTCHK, will clear the text INH when recorded. Box 19 - Min-Mode The box 19 indicator shows the states of application min-mode. When this box is backlighted, no call processing functions are allowed in the AM. This is only used in extreme emergencies to prevent customer actions from interfering with machine operations. Min-mode is invoked and deleted via EAI application pokes ``M'' and ``N,'' respectively. The request will display INH when recorded. This inhibit will take effect immediately with the request following the next major AM initialization. The request will clear the text INH when recorded and take effect on the next major AM initialization. Box 20 - Message Brevity Control The box 20 indicator gives inhibit status of message brevity control for all messages originating from the application processes in the AM only. Entering inhibit command 620 generates the message INH:BREVC,AM. The request will display INH when recorded. This inhibit will take effect immediately with the request. Entering the allow command 720 generates ALW:BREVC,AM. The request will clear the text INH when recorded. This inhibit is cleared by any high-level AM initialization. Box 21 - Recent Change Backout The box 21 indicator shows whether or not uncommitted (recently entered) AM recent changes are loaded or backed out. Backout can only occur as a result of an AM high-level initialization. The description portion shows when the recent changes are actually backed out or loaded. If the backout is in progress, a number will appear on the third line of the box showing the progress of the backout. From 200 down to 100 is CORC backout; 200 meaning CORC is still fully backed out, and 100 meaning CORC is fully rolled forward. From 100 down to 0 is RC backout; 100 meaning RC is still fully backed out, and 0 meaning RC is fully rolled forward. Recent changes can be backed out only in conjunction with a high-level initialization. Recent changes should be backed out if a recent change is suspected to be the cause of an AM performance problem. When the command 421 is entered, the message SET:BACKOUT,RC,AM is generated. The request will display SET when recorded. The request state does not necessarily imply that the set is in effect. When the command 521 is entered, the message CLR:BACKOUT,RC,AM is sent. The request will clear the text SET when recorded. The request state does not imply that the backout has been cleared. Boxes 22 Through 27 - Boxes 22 through 27 are not currently used. Figure .AW G149/ is an example of the 110 page display which shows one system inhibit set and two AM inhibits set. Routine Exercises in box 17 has been inhibited. Box 21 shows RC BACKOUT is currently set and has been partially backed out (80%). However, the top line is normal video and there is no SET text after the 21. This indicates that the craft does not desire the recent changes to be kept out. In addition to the following commands, all available display commands can be accessed from Display Page 110. 2 CMD RESULT 421 RC Backout (AM) is set (SET:BACKOUT,RC,AM) 521 RC Backout (AM) is cleared (CLR:BACKOUT,RC,AM) 604 Manual RC is inhibited (INH:RC) 606 RC Logging is inhibited (INH:RCLOG) 608 CLNK Normalization is inhibited (INH:CLNORM) 609 CAMA is inhibited (suspended) (INH:CAMAONI) 616 Routine Audits (AM) are inhibited (INH:AUD=CYCLE,ENV) 617 Routine Exercises (CM) are inhibited (INH:REX,CM) 620 Message Brevity Control (AM) is inhibited (INH:BREVC,AM) 701 Message Class Brevity Control is allowed (ALW:BREVC,MSGCLS=ALL) 704 Manual RC is allowed (ALW:RC) 706 RC Logging is allowed (ALW:RCLOG) 708 CLNK Normalization is allowed (ALW:CLNORM) 709 CAMA is allowed (no longer suspended) (ALW:CAMAONI) 716 Routine Audits (AM) are allowed (ALW:AUD=CYCLE,ENV) 717 Routine Exercises (CM) are allowed (ALW:REX,CM) 720 Message Brevity Control (AM) is allowed (ALW:BREVC,AM) 902 Message Class Log/Print Status is output (OP:LPS<MSGCLS=ALL) 903 MDII Report is output (OP:MDII) 905 CORC Status is output (OP:STAT,CORC,ACSR) 910 Trunk Hold list is output (OP:TRUNK) 916 Routine Audits (AM) are output (OP:AUD,STATUS=ALL,ENV) 917 Routine Exercises (CM) are output (OP:REXINH,CM) The purpose of the 111/112 display page is to report status of the AM and its peripherals. The AM is an AT&T 3B20 duplex computer. In addition to the AM and peripheral indicators on this display, there are additional indicators for Page 121 - IOP 0 & 1, Page 122 - IOP 2 & 3, Page 123 - DISK FILE SYSTEM ACCESS for DFC 0-1, Page 125 - DISK FILE SYSTEM ACCESS for DFC 2-3, and Page 113 - OPERATIONS SYSTEMS LINKS. If common network interface (CNI) is equipped, there is also an indicator pointing to Page 118 - CNI FRAME AND CCS LINK STATUS. An off-normal condition on this page will cause the AM or AM PERPH indicator at the top of the screen to backlight. An off- normal condition in an MHD (Page 123) will backlight the ``SEE PAGE 123'' indicator and the AM PERPH at the top of the screen. Also, an off-normal condition in an MHD (Page 125) will backlight the ``SEE PAGE 125'' indicator and the AM PERPH at the top of the screen. An off-normal condition on Page 121 will backlight the ``SEE PAGE 121'' indicator(s) and the AM PERPH at the top of the screen. An off-normal condition on Page 122 will backlight the ``SEE PAGE 122'' indicator(s) and the AM PERPH at the top of the screen. An off-normal condition on Page 118 will backlight the ``SEE PAGE 118'' indicator and the AM PERPH at the top of the screen if CNI is equipped. An off-normal condition in the SCCs will cause the ``TO SCC 0'' or ``TO SCC 1'' indicator to backlight, and the OS LINKS indicator at the top of the screen will backlight. In all these cases, the appropriate alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. Figure .AW G150/ shows various off-normal conditions in the AM and its peripherals. The CSU 1 and AM 1 are unavailable. This caused the AM indicator at the top of the screen to backlight. An MHD on Page 123 is out of service, causing the SEE PAGE 123 to backlight, and there is a problem on Page 121 with some device or devices connected to IOP controller 0. These two conditions have caused the AM PERPH indicator at the top of the screen to backlight. Also, SCC 1 is either out of service, unavailable, or being initialized, which is shown by backlighting in the TO SCC 1 indicator at the bottom right-hand portion of the display. This off-normal SCC condition caused the OS LINKS indicator at the top of the screen to backlight. The 111/112 page provides commands to remove, restore, diagnose, and switch the various units. Also, output commands are available for out-of-service and diagnostic listings. All available displays can be accessed from the 111/112 page. 2 CMD RESULT CMD RESULT 20X AM X is removed 30X AM X is restored (RMV:CU=X) (RST:CU=X)[,UCL] 21X DFC X is removed 31X DFC X is restored (RMV:DFC=X) (RST:DFC=X)[,UCL] 23X IOP X is removed 33X IOP X is restored (RMV:IOP=X) (RST:IOP=X)[,UCL] 24X MTTYC X is removed 34X MTTYC X is restored (RMV:MTTYC=X) (RST:MTTYC=X)[,UCL] 25X MTTY X is removed 35X MTTY X is restored (RMV:MTTY=X) (RST:MTTY=X)[,UCL] 26X ROP X is removed 36X ROP X is restored (RMV:ROP=X) (RST:ROP=X)[,UCL] 50X AM X is diagnosed 400 AM is switched (DGN:CU=X)[,UCL] (SW:CU) 51X DFC X is diagnosed 401 PORTSW is switched (DGN:DFC=X)[,UCL][,CONT] (SW:PORTSW) 53X IOP X is diagnosed 402 ROP is switched (DGN:IOP=X)[,CONT][,UCL] (SW:PORTSW:ROP) 54X MTTYC X is diagnosed 403 MTTY is switched (DGN:MTTYC=X)[,UCL][,CONT] (SW:PORTSW:MTTY) 404 OOS units are listed at ROP (OP:CFGSTAT,OOS) 405 Diagnostic request queue is output at ROP, including restore/remove requests (OP:DMQ,AM) The 113 display page provides a listing of Operations Systems links and their status. There are various types of Operations Systems which can be linked to an office. These systems provide additional services to an office. Some of the systems which may appear on this display are discussed in the following paragraphs. The Automatic Message Accounting Data Link (AMADL) connects the Automatic Message Accounting Teleprocessing System (AMATPS) with a Revenue Accounting Office (RAO). The AMATPS assembles billing data. The Centralized Automatic Reporting on Trunks (CAROT) automatically accesses and tests trunks. The Centralized Trunk Test Unit (CTTU) is a test position for remote trunk and line testing. The Engineering and Administration Data Acquisition System (EADAS) collects, stores, and analyzes the traffic data. The Mechanized Loop Testing System Generation 2 (MLT2) is used for testing and analyzing the condition of customer loops for the Automated Repair Service Bureau (ARSB). The No. 2 Service Evaluation System (NO2SES) provides large volume service evaluation and incorrect answer supervision identification. The Operator Services Position System Recent Change (OSPSRC) link provides restricted recent change/verify access to OSPS data on the 5ESS(R) switch. The Remote Memory Administration System (RMAS) provides standard recent change/verify access. It prints office records, provides on-line growth capability for many recent changes, and provides an on-line error-checking capability. The Software Change Administration and Notification System 2 (SCANS2) is used to transmit Broadcast Warning Messages (BWMs) to both the office and the Switching Control Center (SCC). The No. 2 SCC provides facilities to administer, monitor, control, and maintain the 5ESS switch from a remote, centralized location. The Testing, Operations, Provisioning, and Administration System (TOPAS) link provides centralized trunk maintenance and administration for trunks terminating on 5ESS switch toll configurations. There are several columns of information shown for each system. The first column, OS, is the standard link abbreviation (for example, AMADL2). The next column, LINK, shows whether the link is primary or secondary. The TYPE column shows whether the link is dedicated or dial-up. The DEVICE column contains the abbreviation of the peripheral device and the status of the link. The PC NAME is the name of the peripheral controller for the assigned peripheral device. This column is for information only. It does not show status. Status for the peripheral controllers is found on 121 - IOP 0 and 1 or 122 - IOP 2 and 3. The last two columns, TIME BUFF and DATA BUFF are used to show time and data buffer overflows. These columns are not applicable (N/A) to many of the systems. Any off-normal condition on this page will cause the OS LINK indicator at the top of the screen to backlight. The appropriate alarm level indicator (CRITICAL, MAJOR, or MINOR) will backlight, if applicable. The operations systems links vary from one office to another. Figure .AW G151/ shows SCC 1 is unavailable, which can be determined from the backlighted indicator and accompanying status text (UNAV). Commands are available to remove and restore the SCCs. All available displays are also accessible from the 113 display page. CMD RESULT 200 SCC 0 is removed (RMV:SCC=0) 201 SCC 1 is removed (RMV:SCC=1) 300 SCC 0 is restored (RST:SCC=0,UCL) 301 SCC 1 is restored (RST:SCC=1,UCL) The purpose of the 114 page is to provide a summary of all equipped switching modules (SM) and their operational states. Each equipped SM has a unique indicator on the 114 display. The indicator has two distinct sections: o SM NUMBER: There may be gaps in SM numbering for a particular office. To provide flexibility in office numbering schemes, the SM numbers are not necessarily assigned sequentially. If an SM is not equipped, it is not listed. An example of this is shown in the 114 page example (Figure .AW G152/) by the blank indicators between SM 12 and SM 20, SM 20 and SM 24, etc. o SM TYPE: This is a 1-character designation to show how an SM is being used. For example, an L is an LSM which is a local switching module. When a new alarm condition on an SM happens, the SM indicator will begin flashing. The ALM RLS key will not stop the flashing. The color of the flashing may not reflect the new alarm if the previously recorded condition is of higher priority. To stop the flashing, the craft should display the 1010 Page for that SM. There is also a command to retire the flashing (999). This is mainly provided for situations such as during installation when SMs are being grown in and many SMs are displaying recurrent error conditions. For further details on any SM recovery related activity or SM inhibits, the craft would enter 1800,X to display the SM X INHIBIT AND RECOVERY CONTROL page. This is the SM control page for emergency action. A lower level summary page for observing up to 48 SMs simultaneously can be requested by entering 141 (SMs 1 - 48), 142 (SMs 49 - 96), 143 (SMs 97 - 144), or 144 (SMs 145 - 192). For details on any backlighted SM, the craft would enter 1010,X to display the SM X STATUS page. This page can be accessed during SM X initialization or if SM X is isolated, but the only status that will fill in are the SM STAT and RELATED PAGES boxes. In Figure .AW G152/, LSMs 1, 3, and 6 and HSM 10 and RSMs 48 and 120 are backlighted due to an off-normal condition in each. All available paging commands can be entered from the 114 display page. CMD RESULT 141 SM 1 - 48 page is displayed 142 SM 49 - 96 page is displayed 143 SM 97 - 144 page is displayed 144 SM 145 - 192 page is displayed 999 SM flashing is retired 1000 SM INDEX page is displayed 1010,X SM X STATUS page is displayed 1600,SZ SITE Z STATUS page is displayed 1610 REMOTE SITE INDEX page is displayed The purpose of the 115 display page is to provide a summary of off-normal status for the hardware units and links which control AM to SM(s) communication and provide paths for all circuit switched calls. The 115 display page has two separate and distinct versions. The first version (Figure .AW G153/) is for offices with communication module model 2 (CM2) hardware. The second version (Figure .AW G154/) is for offices with CM1 hardware. The 115 page provides overall status for MSGS 0, MSGS 1, MI/NC 0 (MI/LI/NC 0 for CM1), MI/NC 1 (MI/LI/NC 1 for CM1), TMS 0, TMS 1, communication links for the SMs, fan and fan fuse alarms for the ONTCs (for the MSGSs and TMSs for CM1), the status of the hardware check inhibit request bit, and the status of the MI/NC/TMSs (MI/LI/NC/TMSs for CM1) functioning as a group (ONTCCOM). The ONTCCOM 0 includes MI 0 (LI 0 in CM1), NC 0, and TMS 0. The ONTC 0 includes ONTCCOM 0 and all DLIs on side 0. The ONTCCOM 1 includes MI 1 (LI 1 in CM1), NC 1, and TMS 1. The ONTC 1 includes ONTCCOM 1 and all DLIs on side 1. If an MSGS, MI/NC (MI/LI/NC in CM1), or TMSLNK has an off-normal condition (out of service not family of equipment, unavailable, hardware checks inhibited, or off-normal software status), the appropriate indicator with the page number of the MCC page with the detailed information is backlighted. The phrase ``SEE PAGE XXXX IF BACKLIT'' is backlighted when any of the boxes are backlighted to point out that the numbers in the boxes are the page numbers to request. Note: The 1210 boxes are backlighted only for NC reference or oscillator problems. The CLNKS indicator is a summary of the equipped SM communication links status which is detailed on Page 1260. The CLNKS are not TMS links. The TMS links are part of the TMS. Communication links consist of several components, one of which is the TMSLNK. The indicator in the center, CM HDWCHK INH REQ, only appears on the page if the data delivery request automatic hardware check bit is set (due to automatic escalation or manual request). It indicates that there is an inhibit request for all CM hardware checks. This means that at the next high-level AM initialization, all application hardware checks will be inhibited. This bit can be manually set and cleared by the input messages INH:HDWCHK and ALW:HDWCHK, respectively. Note that allowing hardware checks on all the CM units individually will not clear the bit, and this indicator will remain on the page. The backlighted indicator indicates the page necessary for acting on the problem. As an example, the box with 1242 indicated is backlighted in the page example shown in Figure .AW G153/ because a module message processor (MMP) on Display Page 1242 is shown as out of service (OOS). The MMP out of service is also reflected on the MSGS 0 Page 1240, but going to 1240 would not be the final step to see and act on the problem so the MSGS 0 box with 1240 indicated is not backlighted. If a foundation peripheral controller (FPC) or pump peripheral controller (PPC) was out of service also, then the MSGS 0 box would backlight as shown in Figure .AW G154/. The purpose of this strategy is to get the craft directly to the problem with minimum paging. Therefore, if the 1240 (MSGS 0) box and the 1241 (or 1242) were both backlighted, an out of service (not family of equipment), an unavailable, an out-of-service power, or an unavailable power condition would exist in an MMP, FPC, PPC, or CMP and an MSCU. The TMS 0 and 1 boxes (indicating Page 1220) will never backlight. If a TMS is OOS, it would be due to the whole ONTC being OOS or UNV; therefore, 1209 is the appropriate page to display. The indicator FPC DPLF is displayed to signal FPC duplex failure or CM ISOL is displayed to indicate manual CM isolation. A separate indicator is displayed to indicate if the data delivery manual CM isolation request bit is set. The 115 page display example in Figure .AW G153/ shows problems in MI/NC 1, MSGS 0, TMS 0, CLNKS, and ONTC 1. Further information on these problems would be found on display 1210 - MI/NC 0 & 1, 1242 - MSGS 0 - COMMUNITIES 2 - 7, 1221 - TMS 0 TMS LINKS 002 - 063, 1260 - CLNK SUMMARY, and 1209 - ONTC 0 & 1. There is a fan alarm on ONTC 0 and the ONTC 1 Fan Fuse Alarm is inhibited. The CM isolation indicator is showing that CM isolation is in effect. Also, the hardware check inhibit request bit is set. Figure .AW G154/ is an example of the 115 summary display that shows problems in MI/LI/NC 1, MSGS 0, TMS 0, CLNKS, and ONTC 0. Further information on these problems would be found on displays 1210 - MI/LI/NC 0 & 1, 1240 - MSGS 0 SUMMARY, 1221 - TMS 0 - TMS LINKS 002 - 063, 1260 - CLNK SUMMARY, and 1209 - ONTC 0 & 1. There is a fan alarm on MSGS 0 and the TMS 0 fan fuse alarm is inhibited. The indicator is signaling that FPC duplex failure is in effect. There are no menu commands on the 115 display page. Commands for removing, restoring, diagnosing, etc., are listed on the related pages. There are no menu commands on the displays for fans or fan fuses. For fans or fan fuses, see CLR:FANALM in AT&T 235- 600-700, Input Messages Manual. All available display commands can be entered from the 115 display page. The 116 display page provides status for various units/activities which do not fall under any other grouping. The External Sanity Monitor (ESM) has indicators for alarm, inhibit, and power. If an alarm or an inhibit is present, the appropriate indicator will backlight. If power is off, the POWER indicator will backlight and the word OFF will be displayed. The CALL MONITOR indicator shows whether the Call Monitor is inhibited or allowed. Entering the command 601 generates the message INH:CALLMON which will inhibit the monitor from making test calls and performing call completion analysis. This also clears the monitor's history data. The command 701 generates the message ALW:CALLMON which allows the monitor to start the cycle of making test calls and performing call completion analysis. Command 801 generates the message RTR:CALLMON,ALARM which retires the alarm indicator in the Call Monitor box. Command 901 generates the message OP:CALLMON which generates the OP CALLMON PAST 15 MINUTE REPORT on the ROP. The indicators FRAME FUSE and FRAME FAN are for the miscellaneous frame. If a fuse or fan alarm is present on the miscellaneous frame, the corresponding indicator will backlight. The fuse must be replaced to correct the frame fuse alarm. The fan must be restored to operating condition to correct the frame fan alarm. The input command CLR:FANALM,MFFAN can be entered to clear the frame fan alarm after the alarm condition is fixed. If a system inhibit is present, the word INH will be displayed and backlighted to the right of the indicator label. The fuse and fan alarms can only be inhibited by the system. An inhibit means a scan point is chattering. The input command ALW:ALM,MFFAN can be entered to allow the scan point after the chattering problem is fixed. The indicator GENERIC RETROFIT will backlight and change to GENERIC RETROFIT ACTIVE when software release (generic) retrofit is in progress. The indicator ODD EVOL will backlight and change to ODD EVOL ACT when ODD Evolution is in progress. THE ODD Evolution is initiated by the command BKUP:ODD,ODDEVOL and stays in effect until the actual software release cutover takes place. The indicator OSPS EVOL will backlight and change to OSPS EVOL ACT when OSPS Evolution is in progress. The OSPS Evolution is initiated by the command BKUP:ODD,ODDEVOL if the office has an OSPS configuration active. It stays in effect until the actual software release cutover takes place. The RC BACKUP indicator normally shows NORMAL on the right part of the indicator. If RC Backup fails in the AM, the text NORMAL changes to FAILURE and the entire indicator backlights. The MISCELLANEOUS ALARMS indicator has two subindicators: ALARM and INHIBIT. These subindicators are backlighted for any alarm and/or inhibit conditions present on the MISCELLANEOUS ALARMS display. For additional information, enter command 119. The next indicator, MTIB, will backlight if an off-normal condition exists on the MTIB display. Enter command 127 for further details. In the CUTOVER indicator, the word ACTIVE will backlight if an off-normal condition exists on the CUTOVER display (cutover enabled, for example). Further information can be found on display 197 - CUTOVER. Any off-normal condition will cause the MISC indicator in the SUMMARY STATUS AREA at the top of the screen to backlight. Figure .AW G155/ is an example of the 116 display page which shows an alarm and an inhibit present on 119 - MISCELLANEOUS ALARMS. There is also something off-normal on Page 127 - MTIB STATUS. These have caused the MISC status summary indicator at the top of the screen to backlight. Commands are provided to inhibit and allow the ESM and to clear (retire) the exit pilot lamps. Commands are also provided to inhibit and allow the call monitor, output the past 15-minute interval history for the call monitor, and retire a call monitor alarm. Also, all available displays can be accessed from the 116 display page. CMD RESULT 600 External Sanity Monitor is inhibited (INH:ALM,ESM) 601 Call Monitor is inhibited (INH:CALLMON) 700 External Sanity Monitor is allowed (ALW:ALM,ESM) 701 Call Monitor is allowed (ALW:CALLMON) 800 Exit Pilot Lamps are cleared (retired) (CLR:LAMPS) 801 Call Monitor alarm is retired (RTR:CALLMON,ALARM) 901 Call Monitor history is output (OP:CALLMON) The purpose of the 117 page display is to provide a summary of information associated with the application processor data links (APDL). The 113 page indicates that maintenance personnel can display the 117 page, if desired. The following items contain detailed information concerning each field in the 117 page display: o LINK: This field identifies the link by name (for example, APDL01). The 01 attached to the APDL is the link number of the link that is added to tuple relation RLCMAPDATA. The link number is between 1 and 6 that corresponds to the number assigned to that link via RC/V view 24.1. o PORT: This field indicates the data link connected to the administrative module-input/output processor (AM-IOP). o MODULE: This field indicates the data link is connected to the AM-IOP. o DEVICE: This field identifies the PC port and the hardware status. The possible states are as follows: active (ACT), out of service (OOS), initialization (INIT), or growth (GROW). Also, the UCB of the SDL is indicated. For example, in SDL 42 OOS, 42 is the UCB of the SDL. o PC NAME: This field identifies the PC on which the port is located. For application processor (AP) data links, there is only one port per PC. o SITE_ID: This field identifies the AP to which the link is connected (also known as the AP). The SITE_ID number matches the key field on RC/V view 24.1. o SESSION: This field indicates the BX.25 session status over a given link. The possible states are as follows: connected (CONN), disconnected (DISC), or initialization (INIT). Figure .AW G156/ shows an example of the 117 page display. Any of the available page displays can be accessed from the 117 page display. CMD RESULT 121 Peripheral controller status is displayed -- IOP 0 & 1 122 Peripheral controller status is displayed -- IOP 2 & 3 The purpose of the 118 page is to provide status and maintenance commands for the common network interface ring peripheral controller nodes (RPCN), link nodes (LN), and direct link nodes (DLN). The function of the DLN (an optional capability) is to relieve the AM real-time capacity constraint caused by common channel signaling (CCS). This is accomplished by moving CCS signaling message processing from the AM to the DLN. The DLN is equipped as two independent simplex ring nodes operating in active/standby mode; meaning, one DLN is active, while the other is in the standby mode ready to be switched to active. Call- related signaling messages are routed onto the ring to the DLN instead of the existing ring peripheral controller (RPC). Ring maintenance, link security, and administrative messages are still processed in the AM via the RPC. When the DLN option is equipped, the common network interface (CNI) frame has a physical limitation of five LNs per group. The DLNs are assigned to LN member position 2 in both groups 00 and 32 and are indicated ``DLN.'' Also, the signaling link status LN(00/32)-2 is blank. The 118 page is divided into three basic areas. The box at the left side of the display is the status indicator and reflects the overall CNI status. The status displayed here can be one of the following (where DSIG = direct signaling, TSIG = trunk signaling, and TCAP = transaction capability): o DSIG ACT: If the GLDSSPEED is 48 and office is equipped with 4.8 kbps links, or if the GLDSSPEED is 560 and office is equipped with 56 kbps links, the status indicator block will contain ``DSIG ACT'' (indicating the appropriate links are active). o DSIG OOS: If the GLDSSPEED is 48 and the office is equipped with 4.8 kbps links, or if the GLDSSPEED is 560 and the office is equipped with 56 kbps links, and the link (4.8 kbps or 56 kbps) is OOS, the status indicator block will contain ``DSIG OOS''. o DSIG UNEQ: If the GLDSSPEED is 48 and the office is only equipped with 56 kbps links, or if the GLDSSPEED is 560 and the office is only equipped with 4.8 kbps, the status indicator block will contain ``DSIG UNEQ''. o TSIG ACT: If the RLPCIPRT relation has tuples populated and one of the available links is active, the status indicator block will contain ``TSIG ACT''. o TSIG OOS: If the RLPCIPRT relation has tuples populated and all available links are OOS, the status indicator block will contain ``TSIG OOS''. o TSIG UNEQ: If the RLPCIPRT relation has no tuples populated, the status indicator block will contain ``TSIG UNEQ''. o TCAP ACT: If the RLDS_APP relation has tuples populated and the 56 kbps links are active, the status indicator block will contain ``TCAP ACT''. o TCAP OOS: If the RLDS_APP relation has tuples populated and the 56 kbps links are OOS, the status indicator block will contain ``TCAP OOS''. o TCAP UNEQ: If the RLDS_APP relation has no tuples populated, the status indicator block will contain ``TCAP UNEQ''. During CNI ring initializations, the DSIG, TSIG, and TCAP indicators in the STATUS box will show INIT. When the status is INIT, no other information on the display page can be considered accurate until the initialization has completed. The box in the middle of the display shows the node status. There are two columns within this area; the first column is the major status of the nodes, and the second column is the minor status of the nodes. The major status can be one of five states: o ACT: This indicates that the RPCN, LN, or DLN is active. o OOS: This indicates that the RPCN, LN, or DLN is out of service. o STBY: This indicates that the RPCN, LN, or DLN is in standby. o GROW: This indicates that the RPCN, LN, and DLN is in the growth state. o UNEQ: This indicates that the node is unequipped. The minor status can be one of four states: o ISO: This indicates that the node is isolated. o BISO: This indicates that the node is beginning isolation. o EISO: This indicates that isolation is ending. o NORM: This indicates that the node is normal. The boxes on the right side of the display provide the link status. The first column in the link status area shows the 11- character far-end CLLI code of the link. The second column is the major state, the third column is the minor state, and the fourth column is the processor outage (PRO) received status. The major status can be one of three states: o AVAL: This indicates that the link is available. o UNAL: This indicates that the link is not available. o UNEQ: This indicates that the link is unequipped. The minor status can be one of six states: o IS: This indicates that the link is in service. o OOS: This indicates that the link is OOS. o MOOS: This indicates that the link is in a manual OOS state. o GROW: This indicates that the link is in the growth state. o TEST: This indicates that the link is being tested. o UNAV: This indicates that the link is not available. The PRO RCVD column is an indication of a processor outage received from the signal transfer point and is either YES or NO. Any off-normal condition in the middle section of the page (the RPCNs or the LNs) will cause the SEE PAGE 118 indicator on the 111/112 page to be backlighted. In the SUMMARY STATUS AREA, the AM PERPH critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Two additional status indicators are the ring status indicator (RSI) and the automatic ring recovery (ARR) shown as follows: 1. Ring Status Indicator: This indicator appears at the top left-hand side of the 118 page under the system alarm indicators. Its purpose is to show the state of the CNI ring. The following lists the possible values and their meanings: o ACTIVE: The CNI ring has all nodes active. o DOWN: The CNI ring has a critical problem and no CCS call processing can be completed. o ISOLATED SEGMENT: The ring has one or more nodes under diagnostics which requires a quarantine or isolation of the node. o RESTORING: Indicates that the node is being pumped and should soon go ACT. o CONFIGURING: The ring has just RESTORED a node and the ring is propagating the token to allow the node back into service with the rest of the ring. 2. Automatic Ring Recovery (ARR): The ARR indicators are not seen on the 118 page until a node is faulted. Once a node is down and ARR attempts to recover the node, the appropriate indicator will light. The ARR has three indicators which will appear at the bottom left hand corner of the 118 page just under the diagnostic pokes. The indicators will show the type of recovery being done and which node is currently being worked on. If more than one node is down, then an OP:DMQ may be performed at the bottom of the MCC to see if the node has been queued for restoral by ARR. The following is the possible outputs of each indicator. a. First Indicator outputs are as follows: o ARR UCL: The ARR will attempt to restore the node without running diagnostics. o ARR COND: The ARR will attempt to restore the node but will run diagnostics first. o CNR UCL: The ARR has detected that a duplex failure has occurred and that restoration of the node will be done without running diagnostics. o CNR COND: The ARR has detected that a duplex failure has occurred and that the node will be run under diagnostics before restoration. b. Second Indicator outputs are as follows: o ARR RSTRT: The ARR is restarting the node. This indicator can be lighted at the same time any of the preceding indicators are on. o CNR RSTRT: The ARR has detected the duplex failure and is restarting the node. This indicator can also be lighted at the same time any of the preceding indicators are lighted. c. Third Indicator outputs are as follows: o ACNR UCL: The ARR has detected the duplex failure of the Direct Link Nodes (DLNs). An unconditional restoral will be performed on the DLN listed. o ACNR COND: The same as ACNR UCL except that ARR will run diagnostics before restoring the node. o ACNR RSTRT: The same as CNR RSTRT except this indicator deals with the restart of the DLN node only. Figure .AW G157/ shows an example of the 118 page. The frame status for the DLNs are divided into two categories. The ``aaaa'' field illustrates the major states of the DLN, and the ``bbbb'' field illustrates the minor states. The 118 page provides commands to remove, restore, and diagnose the RPCNs and the DLNs and to output any off-normal conditions for the ring or the signal link. All available displays can be accessed from the 118 page. 2 CMD RESULT 20XX RPCN XX is removed from service (RMV:RPCNXX=0) (XX can only be 00 or 32) 21XXY LNXX Y is removed from service (RMV:LNXX=Y) (XX can only be 00 or 32 and Y can only be 1 through 6) 22XX2 DLNXX 2 is removed from service (RMV:LNXX=2) (XX can only be 00 or 32) 30XX RPCNXX is restored to service conditionally [or unconditionally] (RST:RPCNXX=0,RAW,TLP)[,UCL] (XX can only be 00 or 32) 31XXY LNXXY is restored to service conditionally [or unconditionally] (RST:LNXX=Y,RAW,TLP)[,UCL] (XX can only be 00 or 32 and Y can only be 1 through 6) 32XX2 DLNXX 2 is restored to service conditionally [or unconditionally] (RST:LNXX=2,RAW,TLP)[,UCL] (XX can only be 00 or 32) 50XX RPCN XX is diagnosed (DGN:RPCNXX=0,RAW,TLP)[,RPT=a][,PH=b[&&c]] (XX can only be 00 or 32) a is the number of times the diagnose is to be repeated b is the phase b&&c is the range of phases to be performed 51XXY LNXX Y is diagnosed (DGN:LNXX=Y,RAW,TLP)[,RPT=a][,PH=b[&&c]] (XX can only be 00 or 32 and Y can only be 1 through 6) a is the number of times the diagnose is to be repeated b is the phase b&&c is the range of phases to be performed 52XX2 DLNXX 2 is diagnosed (DGN:LNXX=2,RAW,TLP)[,RPT=a][,PH=b[&&c]] (XX can only be 00 or 32) a is the number of times the diagnose is to be repeated b is the phase b&&c is the range of phases to be performed 900 Status of a RING is printed (OP:RING:DETD) 901 Status of the signaling links is printed (OP:SLK=ALL,DEST=1) The 119 display page summarizes status and assignment and provides inhibit/allow controls for miscellaneous alarms. Miscellaneous Alarms and their alarm levels are office assignable. The alarm level and text in these indicators are initially filled in using a TTY input message (CHG:ALM,MISC=miscellaneous alarm number, TAG=text to be filled in, LVL=CR, MJ, MN, or IF). Once these indicators are filled in, they are protected from loss if the system is booted. When an alarm condition occurs and is not inhibited, the respective display indicator backlights to the TROUBLE state. This in turn causes ALARM to backlight in the Miscellaneous Alarms Indicator on Page 116. In the SUMMARY STATUS AREA, the associated alarm level (CRITICAL, MAJOR, or MINOR) will backlight, and MISC will start flashing. Also, an audible alarm will be sounded. When an alarm is inhibited, the respective indicator will show INH, and the INH will be backlighted. On Page 116, INHIBIT in the Miscellaneous Alarms Indicator will also backlight. The MISC indicator at the top of the screen will backlight to the TROUBLE state. Figure .AW G158/ is an example of the 119 display page in which indicator 03 shows a major alarm caused by a failure in the MFT bay. Indicator 06 shows the SLC P/M 1 is inhibited from triggering an alarm. Commands are provided to inhibit and allow the miscellaneous alarms. All available displays are accessible from the 119 display page. CMD RESULT 6XX Miscellaneous Alarm XX is inhibited (INH:ALM,MISC=XX) 7XX Miscellaneous Alarm XX is allowed (ALW:ALM,MISC=XX) Display Page 120 provides full-page TTY message viewing. When Page 120 is displayed, TTY messages scroll into the region normally used for displays. Figure .AW G159/ is an example of the 120 display page. There are no commands for the 120 page. The purpose of the 121 and 122 pages is to provide status and assignment of all input/output processor (IOP) peripheral control devices. The displays for IOP 0 and 1 and IOP 2 and 3 are very similar. Each IOP has 16 slots for peripheral control devices. Any or all of these slots can be assigned. In the example shown in Figure .AW G160/, scanner and signal distributor controller (SCSDC) 4 and SCSDC 6 are out of service. This causes the SEE PAGE 121 indicator on Page 111/112 to backlight, which in turn backlights the AM PERPH indicator at the top of the display. There are no maintenance commands available from the display for the IOP PC devices. To remove, restore, or diagnose a device, the appropriate TTY input message must be entered instead. Remove messages have the form RMV:dev=a, where a is the device number. For example, to remove MTTYC 0, the input message is RMV:MTTYC=0. Restore and diagnose messages are the same, except for the verb. For example, to diagnose SCSDC 4, the input message is DGN:SCSDC=4. All available page commands can be entered from the 121 and 122 display pages. The purpose of the 123 display page is to provide status and maintenance commands for two disk file controllers (DFC) and up to 16 moving head disks (MHD). It also provides status and commands for disk independent operation (DIOP) when both essential disks are lost and status of the Auto MHD Configuration feature. A 5ESS switch office can have Storage Module Device (SMD) only, Small Computer Systems Interface (SCSI) only, or a combination of SMD and SCSI disk subsystem. If there are more than two DFCs in the system, a second DFSA page, Page 125 is used. The format of the 125 page is the same as the 123 except the AUTO MHD CONFIGURATION status is not shown; it appears only on Page 123. The 123 page has three separate and distinct functions. The first function of this page is to provide status and maintenance commands for DFCs 0 and 1 and associated MHDs (up to 16). If the system is equipped with SCSI, this page also provides status and maintenance commands for SCSI buses (SBUS) (up to 4). The second function is to provide status and commands during DIOP. When both of the MHDs that are marked essential (E) go out of service, this page is automatically displayed. This is called full DIOP. The appropriate menu commands to use under these circumstances are the 600 series of commands. When in full DIOP (Figure .AW G162/), a 620 command will appear which will allow the MHD to be reloaded from tape without bringing down call processing during the reading of the tape. When the MHD has been reloaded, a minimum of a 52 boot is required. The other 600 series commands, with the exception of the 699 poke, may be used also when not in DIOP. The 699 poke works only in full DIOP. The 602 poke to restore the DFC controller requires UCL when the system is in full DIOP. Neither the 602 or 604 poke will restore associated subunits (MHDs) to prevent accidental disk restoral during disk maintenance. If only one of the essential MHDs goes out of service, the MHDs are in simplex operation (Figure .AW G161/), but the page is not automatically displayed. During full DIOP, the area at the bottom of the page between the two horizontal lines will display output messages for the 600 series menu commands. The third function of the 123 page is to provide for the display of the Automatic MHD Configuration feature. The AUTO MHD CONFIGURATION data displayed on 123 page is a summary status of information from Pages 178, Auto Spare Disk, and 179, Disk Configuration. Possible values of the Automatic MHD Configuration feature are as follows: a. AUTO MHD CONFIGURATION READY: The feature is armed and ready to run if needed. b. SEE PAGE 179, CONFIG MHDs ...: The listed MHDs have been reconfigured; see Page 179 for more data. c. AUTO MHD CONFIGURATION OFF: The feature is turned off. d. MHD CONFIG INHIBITED, SEE PAGE 178: The feature is blocked on one or more MHDs or the entire office; see Page 178 for more data. e. MHD CONFIG IN PROGRESS, SEE PAGE 178: An MHD configuration is in progress; see Page 178 for more data. There are two columns of notations on the right side of each of the MHD status columns. The first of the two columns contains one of two letters: o Y - (Yes): This means the MHD was diagnosed or restored since the last system initialization and appears to be usable. o N - (No): This means the MHD was not diagnosed or restored since the last system initialization and does not appear to be usable. The second column contains the letter E which signifies that the associated MHD is essential. The upper two display fields, OPTION LEVEL and CURRENT LEVEL, inform the user of the optional disk independent operation feature level selected for the operating system and the current disk independent operation state the operating system is in. The OPTION LEVEL displayed will be one of the following: NODIOP Disk independent operation feature is not selected. DIOP Conditional disk independent operation is selected. UCLDIOP Unconditional disk independent operation is selected. The CURRENT LEVEL displayed will be one of the following: NORMAL Normal operating system without disk independent operation mode. SIMPLEX Operating system running with at least one essential MHD out of service. DUPLEX Operating system is running with all duplex essential MHDs active. CONDITIONAL Operating system is in conditional disk independent DIOP operation mode with the last remaining duplex essential MHD about to be removed from service. FULL DIOP Operating system in running with a duplex essential pair of MHDs out of service. For each unit displayed, the following information is shown. 1. Major state of the unit 2. Minor state of the unit (if available) 3. Usability of the unit (Y = usable, N = unusable) 4. Essential status of the unit (E = essential, M = manually nonremovable, blank = nonessential) 5. Microcode status (Firmware of Pumpcode) for the DFC 6. Overload status of a DFC. Figure .AW G161/ shows the simplex version of the disk file system access page for an office with SMD only. In this example, one of the essential MHDs (MHD 1) is OOS, so the current level is marked as SIMPLEX. The OOS MHD caused the AM PERPH indicator at the top of the page to be backlighted. The automatic MHD configuration feature is ready. When the simplex mode is entered, the system begins to lock essential, nonswappable processes from disk into core (AM memory). Upon completion of the locking process, the system will print the message, REPT DIOP SIMPLEX PROCESSING COMPLETED. If the system has problems in locking the essential processes into core, it will print the message, REPT DIOP SIMPLEX UNSWAP FAILURE PID=xx (xx = utility ID of process that failed to lock into memory). This message will reprint every 5 minutes until the locking process is completed. Figure .AW G162/ shows the FULL DIOP version. Figure .AW G163/ shows the simplex version of the disk file system access page for an office with SCSI only or with both SMD and SCSI. The only difference between the SCSI-DFSA and SMD-DFSA versions of the 123 page is the addition of ``SBUS 0 SBUS 2'' under DFC 0, ``SBUS 1 SBUS 3'' under DFC 1 on the SCSI version, and the 604 command for RST/RMV SBUS. Commands are provided to remove, restore, and diagnose the MHDs and to take appropriate actions on the MHDs when one or more essential MHDs are out of service. All available displays can be accessed from the 123 page. 2 CMD RESULT 2XX MHD XX is removed from service (RMV:MHD=XX) 3XX MHD XX is restored to service (RST:MHD=XX) 5XX MHD XX is diagnosed (DGN:MHD=XX) 600,n [v] [s|new] MHD n is formatted (initialized) (INIT:MHD=n) v=VFY. Verify option to be used (default=no verify option). s=Track number or range of tracks to be initialized (default=all tracks). The track number or range of tracks and the ``new'' option can only be used for SMD MHD. 601,n [s] MHD n is verified (VFY:MHD=n) where s represents either: t=XX (XX is track number or range of tracks to be verified) (default=all tracks for SMD MHD) or b=XX (XX is block number or range of blocks to be verified) (default=all blocks for SCSI MHD) (For example: 601,0 b=80&&100 will cause the VFY MHD function to be invoked for MHD 0 and will verify blocks 80 through 100 for SCSI MHD). 602,n [a] DFC n controller only is restored a=UCL (RST:DFC=n,CONT) 603,n [t|fn] Dump MHD n defect table t=Defect table to be dumped:MFGR,COMB,TEMP, ALL,(default=COMB). fn=Full pathname of a file, in double quotes, that the MFGR defect table is to be written to (DUMP:MHD=n:DEFECT) 604,n {opt} RESTORE or REMOVE SBUS {opt} ``RST'' or ``RMV'' (RST:SBUS=n,CONT) (RMV:SBUS=n) Note: For SBUS RST, UCL option is required in full DIOP. 677,n t EIR (Enhanced Information Report) PRINT n=DFC unit number t=EIR format. Valid values are ``n''=turn off EIR PRINT ``l''=long EIR report format, ``s''=short EIR report format 6XX,h HELP OPTION Give help for 600 series commands CMD RESULT 688 Clears the buffer 699 Aborts the menu command that is presently in progress Note: The 699 poke works only while the system disk is in full DIOP. It is not effective in normal or simplex modes. 620,n td a Loads MHD n from tape drive td using sequence a td=Tape device name a=BOTH,GEN,DBONLY or CONT. Note: The 620 poke appears only while the system disk is in full DIOP. It is not effective in normal or simplex modes. Note: The 600 series commands work while the system disk is in full DIOP except that poke 602 (DFC controller only restore) requires UCL. The purpose of the 125 display page is to provide status and maintenance commands for two disk file controllers (DFC) and up to 16 moving head disks (MHD). It also provides status and commands for disk independent operation (DIOP) when both essential disks are lost. A 5ESS switch office can have SMD only, SCSI only, or a combination of SMD and SCSI disk subsystem. The 125 page exists only when there are more than two DFCs in the system. The format of the 125 page is the same as the 123 except the AUTO MHD CONFIGURATION status is not shown; it appears only on Page 123. The 125 page has two separate and distinct functions. The first function of this page is to provide status and maintenance commands for DFCs 2 and 3 and associated MHDs (up to 16). If the system is equipped with SCSI, this page also provides status and commands for SCSI buses (SBUS) (up to 4). The second function is to provide status and commands during DIOP. When in full DIOP, the 125 page will be accessible. The 620 poke (reload from tape option) will only work on the 123 page. The other 600 series commands, with the exception of the 699 poke, may be used also when not in DIOP. The 699 poke works only in full DIOP. The 602 poke to restore the DFC controller requires UCL when the system is in full DIOP. Neither the 602 or 604 poke will restore associated subunits (MHDs) to prevent accidental disk restoral during disk maintenance. If only one of the essential MHDs goes out of service, the MHDs are in simplex operation (Figure .AW G164/), but the page is not automatically displayed. During full DIOP, the area at the bottom of the page between the two horizontal lines will display output messages for the 600 series menu commands. There are two columns of notations on the right side of each of the MHD status columns. The first of the two columns contains one of two letters: o Y (Yes): This means the MHD was diagnosed or restored since the last system initialization and appears to be usable. o N (No): This means the MHD was not diagnosed or restored since the last system initialization and does not appear to be usable. The second column contains the letter E which signifies that the associated MHD is essential. Figure .AW G164/ shows the simplex version of the disk file system access page for an office with SMD only. In this example, one of the essential MHDs (MHD 17) has gone out of service, so the current level is marked as SIMPLEX. The OOS MHD caused the AM PERPH indicator at the top of the page to be backlighted. When the simplex mode is entered, the system begins to lock essential, nonswappable processes from disk into core (AM memory). Upon completion of the locking process, the system will print the message, REPT DIOP SIMPLEX PROCESSING COMPLETED. If the system has problems in locking the essential processes into core, it will print the message, REPT DIOP SIMPLEX UNSWAP FAILURE PID=xx (xx = utility ID of process that failed to lock into memory). This message will reprint every 5 minutes until the locking process is completed. Figure .AW G165/ shows the simplex version of the disk file system access page for an office with SCSI only or with both SMD and SCSI. The only difference between the SCSI-DFSA and SMD-DFSA versions of the 125 page is the addition of ``SBUS 0 SBUS 2'' under DFC 2, ``SBUS 1 SBUS 3'' under DFC 3 on the SCSI version, and the 604 command to RST/RMV SBUS. Commands are provided to remove, restore, and diagnose the MHDs and to take appropriate actions on the MHDs when one or more essential MHDs are out of service. All available displays can be accessed from the 125 page. 2 CMD RESULT 2XX MHD XX is removed from service (RMV:MHD=XX) 3XX MHD XX is restored to service (RST:MHD=XX) 5XX MHD XX is diagnosed (DGN:MHD=XX) 600,n [v] [s|new] MHD n is formatted (initialized) (INIT:MHD=n) v=VFY. Verify option to be used (default=no verify option). s=Track number or range of tracks to be initialized (default=all tracks). The track number or range of tracks and the ``new'' option can only be used for SMD MHD. 601,n [s] MHD n is verified (VFY:MHD=n) where s represents either: t=XX (XX is track number or range of tracks to be verified) (default=all tracks for SMD MHD) or b=XX (XX is block number or range of blocks to be verified) (default=all blocks for SCSI MHD) (For example: 601,0 b=80&&100 will cause the VFY MHD function to be invoked for MHD 0 and will verify blocks 80 through 100 for SCSI MHD). 602,n [a] DFC n controller only is restored a=UCL (RST:DFC=n,CONT) 603,n [t|fn] Dump MHD n defect table t=Defect table to be dumped:MFGR,COMB,TEMP, ALL,(default=COMB). fn=Full pathname of a file, in double quotes, that the MFGR defect table is to be written to (DUMP:MHD=n:DEFECT) 604,n {opt} RESTORE or REMOVE SBUS {opt} ``RST'' or ``RMV'' (RST:SBUS=n,CONT) (RMV:SBUS=n) Note: For SBUS RST, UCL option is required in full DIOP. 677,n t EIR (Enhanced Information Report) PRINT n=DFC unit number t=EIR format. Valid values are ``n''=turn off EIR PRINT ``l''=long EIR report format, ``s''=short EIR report format 6XX,h HELP OPTION Give help for 600 series commands CMD RESULT 688 Clears the buffer 699 Aborts the menu command that is presently in progress Note: The 699 poke works only while the system disk is in full DIOP. It is not effective in normal or simplex modes. 620,n td a Loads MHD n from tape drive td using sequence a td=Tape device name a=BOTH,GEN,DBONLY or CONT. Note: The 620 poke appears only while the system disk is in full DIOP. It is not effective in normal or simplex modes. Note: The 600 series commands work while the system disk is in full DIOP except that poke 602 (DFC controller only restore) requires UCL. The 126 display page provides the optional disk access performance data for the AT&T 3B20D computer. A 5ESS switch office can have SMD only, SCSI only, or a combination of SMD and SCSI disk subsystem. There are a maximum of two DFCs on a DFSA performance page. If there are more than two DFCs in the system, a second DFSA performance page (Page 128) is used. The 126 page can show either SMD-DFSA or SCSI-DFSA, depending on the feature option of the operational office. With the SCSI feature, the DFSA performance data is not available when the operating system is in disk independent operation (DIOP) mode. Meanings of the performance fields displayed are as follows: o CMP: Jobs completed by the DFC for the unit. This field is normalized to show the number of jobs that were completed per second. o AVG: The Average size of the jobs completed for a unit (number of disk blocks). o MAX: The maximum size of a job completed in a time interval (number of disk blocks). Figure .AW G166/ shows an example of the 126 display page for an office with SMD only. Figure .AW G167/ shows an example of the 126 page with mixed SMD and SCSI DFCs. The DFC fields are the sum of the individual MHD fields associated with the DFC. For SCSI DFC, the SBUS fields are the sum of all the MHD fields associated with this SBUS. CMD RESULT 622,S,T Performance updates are displayed S=number of seconds between statistic updates. Valid number of seconds is between 1 and 60. Performance updates will occur 20 times, then will be automatically turned off. If S is defaulted, then performance updates are turned off. T=number of seconds that the performance updates will last. 688 The 3-line communication area at the bottom of the page is cleared. 6XX,h HELP OPTION Give help for 600 series commands The 127 display page shows status and connections for the metallic test interconnect bus (MTIB). The MTIB is used for multiple metallic service units (MSU). Any SM which is equipped with the multiple MSU will have all the MTIB connections. The MTIB CONNECTIONS indicator shows which SMs are equipped with this unit. When an off-normal condition occurs, the MTIB XX indicator backlights and the MTIB indicator on Page 116 - MISCELLANEOUS backlights. In the SUMMARY STATUS AREA, the critical indicator MISC will backlight, as well as the alarm level (CRITICAL, MAJOR, or MINOR) if applicable. In the example shown in Figure .AW G168/, MTIB 5 is out of service. The MTIB CONNECTIONS indicator shows SM 120 uses the MTIBs for the multiple Metallic Service Unit capability. Any SMs shown have all the MTIBs. Commands are provided to remove, restore, and diagnose the MTIB connections. All available displays can be accessed from Display Page 127. CMD RESULT 2XX MTIB XX is removed (RMV:MTIB=XX) [,UCL] 3XX MTIB XX is restored (RST:MTIB=XX) [,UCL] 5XX MTIB XX is diagnosed (DGN:MTIB=XX,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed The 128 display page provides the optional disk access performance data for the AT&T 3B20D computer. A 5ESS switch office can have SMD only, SCSI only, or a combination of SMD and SCSI disk subsystem. There are a maximum of two DFCs on a DFSA performance page. This page is used only when there are more than two DFCs in the system. The 128 page can show either SMD-DFSA or SCSI-DFSA, depending on the feature option of the operational office. With SCSI feature, the DFSA performance data is not available when the operating system is in disk independent operation (DIOP) mode. Meanings of the performance fields displayed are as follows: o CMP: Jobs completed by the DFC for the unit. This field is normalized to show the number of jobs that were completed per second. o AVG: The Average size of the jobs completed for a unit (number of disk blocks). o MAX: The maximum size of a job completed in a time interval (number of disk blocks). Figure .AW G169/ shows an example of the 128 display page with full SCSI DFCs. CMD RESULT 622,S,T Performance updates are displayed S=number of seconds between statistic updates. Valid number of seconds is between 1 and 60. Performance updates will occur 20 times, then will be automatically turned off. If S is defaulted, then performance updates are turned off. T=number of seconds that the performance updates will last. 688 The 3-line communication area at the bottom of the page is cleared. 6XX,h HELP OPTION Give help for 600 series commands The 129 page is a network management (NM) status page for a 5ESS switch with the AUTOVON capability. The 129 page display consists of indicators and data for the AUTOVON capability. An indicator is similar to a LED, the state is either ``ON'' or ``OFF.'' The ``ON'' state identifies the corresponding event has occurred and it is indicated by reverse video. The ``OFF'' state identifies the absence of corresponding event and it is indicated on by normal video. The indicators are updated every 30 seconds. The data items on the 129 page display are the traffic measurements consisting of peg counts, usage counts, and overflow counts. These counts are a portion of the NM 5-minute surveillance data and reflect the traffic measurements in the most recent 5-minute interval. They are updated every 5 minutes. The summary blocks marked as NM and OPERATION consist of the following indicators: o DCCR is turned on when one or more destination code cancellations (DCC) have been initiated for routine level traffic. If no DCC is applied at the 5ESS switch, the DCC indicator is off. o DCCA is turned on when one or more DCCs are applied for all traffic. After all DCCs are removed at all precedence levels, the DCCA indicator goes off. Both DCCR and DCCA may be turned on, indicating at least one DCC is applied to all traffic and at least one for routine traffic. o ARCR is turned on when one or more alternate route cancellations (ARC) are activated at the switch for routine level traffic. When all ARCs are removed, the ARCR indicator is turned off. o ARCA is turned on when one or more ARCs are activated at the switch for routine level traffic. When all ARCs at all precedence levels are removed, the ARCA indicator is turned off. o ESP is turned on if the essential service protection (ESP) is triggered at the switch; otherwise, the ESP indicator stays off. o MC1 is turned on when the switching system is in a machine congestion level 1 (MC1) condition. The MC1 is an indication of system overload. o MC2 is turned on when the switching system is in a machine congestion level 2 (MC2) condition. The MC2 is an indication of severe system overload. o RSM is turned on when one or more remote switching module (RSM) outages exist. The NM and OPERATION status indicators represent occurrence of events related to network management and system operation. When an indicator is seen in reverse video (that is, in the ON state), detailed information may be obtained by entering the appropriate TTY messages and reviewing related MCC page displays. Indicators in these two blocks are updated every 30 seconds. The CIRCUIT block area indicates the traffic data for universal tone decoders (UTD). o UTDMU illustrates the maintenance-usage of UTDs. The UTDs are scanned for maintenance busy every 10 seconds. The count is incremented by one on busy condition. o UTDTU represents the total traffic usage of UTDs. The UTDs are also scanned every 10 seconds to accumulate the usage count. o UTDTO illustrates the total number of attempts to UTDs equipped for the switch. The data in the CIRCUIT block area illustrates the traffic load to common circuits. It suggests the level of load on tone decoders. These counts are used in conjunction with the operation indicators to signal the event of overload. These counts are the first indication of network congestion. The TRAFFIC block area displays the peg counts of eight types of traffic. In terms of direction, calls are of four types: incoming, originating, outgoing, and terminating calls. In terms of call connections, they are divided into four types: tandem (trunk to trunk), intrasystem (line to line), inbound (trunk to line), and outbound (line to trunk). o INC illustrates the number of incoming calls. o OUT illustrates the number of outgoing calls. o ORG illustrates the number of originations. o TRM illustrates the number of calls that terminate in this switch. o TT (trunk to trunk) illustrates the number of tandem calls. The value in this field indicates the level of pressure of through-switched traffic. If tandem traffic peaks, ARC may be applied at the distant switch to get relief. o TL (trunk to line) illustrates the number of inbound calls. o LL (line to line) illustrates the number of intrasystem calls. o LT (line to trunk) illustrates the number of outbound calls. The DELAY block area contains information concerning service response felt by distant switches and subscribers. These counts suggest the performance of the system and the severity of overload. o TRK indicates the percentage of the total sample of the start dial delay (that is, receiver attached delay) exceeding the 3-second threshold. A high number in this field means that other offices are experiencing slow response from this office. This delay increases the time necessary to establish a talking path through the network. o LINE indicates the percentage of total sample of dial tone delay exceeding the threshold. When this field peaks, subscribers are experiencing delays in originating calls. The TRUNK block area provides the NM managers with outgoing attempts per circuit per hour (ACH), outgoing connections per circuit per hour (CCH), and maintenance usage (MU) of trunk groups selected by the NM managers. Each display box within the TRUNK block area illustrates the traffic and maintenance status for a trunk group. The box consists of a display field (trunk group number) and three indicators (ACH, CCH, MU). The trunk group number is displayed on the upper portion of the box. The indicators are located in the lower portion of the box. The video state of the indicators identify the level of MU, ACH, and CCH of the trunk group number identified in the display field (upper portion of the box). The five possible states of an indicator are as follows: STATE VIDEO DISPLAY RANGE 1 Blank Display Below threshold 1 2 Green Steady Between threshold 1 and threshold 2 3 Yellow Steady Between threshold 2 and threshold 3 4 Red Steady Between threshold 3 and threshold 4 5 Red Wink Above threshold 4 Default value for all thresholds are reset by the software controlling the display at each system initialization. However, all of the threshold values can be examined and modified by TTY command. The following display illustrates the default values: THRESHOLD 1 THRESHOLD 2 THRESHOLD 3 THRESHOLD 4 MU 40% 50% 85% 99% ACH 4 8 12 16 CCH 4 8 12 16 Indicators on the TRUNK block area are updated every 5 minutes. During the course of an update, only those indicators that have changed to a new state since the last update are refreshed. A trunk group can be brought up in the display box and removed from the display via a TTY command. Refer to AT&T 235-600-700, Input Messages Manual, for details of the input message. The OFFICE display area identifies the name of the 5ESS switch (with AUTOVON) being monitored. The TIME display area identifies the local time at the 5ESS switch being monitored. Figure .AW G170/ shows an example of the 129 page display. The abbreviations shown on the 129 page display are explained in the text describing this page. Any of the available page displays can be accessed from the 129 page display. The 130 display page provides status of the manual and automatic NM system controls and status of NM circuit conditions. Also, it provides a command to get a listing of all NM controls. When there is an overload in the system there are manual or automatic controls that can be put on the system by Network Management. The 130 page shows the status of these controls, either YES or NO. Any controls on this page that are YES will cause an indicator that refers to this page to appear and be backlighted on Page 109 - OVERLOAD. In the STATUS SUMMARY AREA at the top of the screen, the OVERLOAD status summary indicator will be backlighted. This page also has a reference back to Page 109 that is displayed all the time. Note: The status of DELAYED READINESS is always blank because the feature is not implemented. Figure .AW G171/ shows there is a manual control on the TRUNK GROUP, and transmit (XMT) of dynamic overload control (DOC) is allowed (ALW). The command on this page is provided to print a listing of any NM controls that are YES. Also, any available paging commands can be entered from this display. CMD RESULT 900 Any YES NM controls are output (OP:NMPGE) The 131 page display is a menu page that contains a list of call trace poke commands. An indicator SEE PAGE 132 on the 131 menu page shows the maintenance personnel which hardware call trace page (132 through 139 or 150) to access for the details of the call trace. The 131 menu page gives the user the ability to invoke a trace by simply entering a poke value followed by a number or a set of numbers. For example, 401,2220001 where 401 is the poke for a utility hardware call trace, with a DN (that is, 2220001) being the input option. When tracing ISDN circuit switched lines, the channel to be traced should be included in the input. If no channel is specified, then the default action is to trace the D-channel. See pokes 401 and 405 for input requirements. The SA option is used to specify which subaddress of a DN with multiple call appearances to trace. Specifying SA=ALL will result in Page 150 being populated with the status of all valid subaddresses for the given input. If the SA option is used, the channel option should be omitted. To trace packet switched calls, the PKT variable is included in the following poke commands: 401, 404, 405, and 410. Figure .AW G172/ shows an example of the 131 page display. All of the poke commands that can be invoked by the maintenance personnel appear on the 131 page display. Also, any available page display can be accessed from the 131 menu page. The 132 page is a continuation of the 131 menu page and consists of a list of call trace poke commands. A ``SEE PAGE'' indicator on the 132 menu page shows the maintenance personnel which hardware call trace page (133-140, 150) to access for the details of the call trace. The 132 menu page gives the user the ability to invoke a trace by simply entering a poke value followed by an option or a set of numbers. For example, to trace the active loop of the B1 channel of the operator position terminal 1-135, the poke would be 418,1,135,loop=0,ch=B1. Figure .AW G173/ shows an example of the 132 page display. Refer to the 131 menu page for all of the poke commands that can be invoked by the maintenance personnel. Also, any available page display can be accessed from the 131 menu page. The hardware call trace page displays (133 through 138) show the hardware paths of calls requested to be traced. The 133 through 138 pages allow the LCEN and ISLU information to be displayed. The ISLU information includes the type of circuit switched service (for example, voice or data) and a B-channel identifier (B1, B2, or ON HOLD). The ``ON HOLD'' indicates that no B- channel is allocated for the call. These call trace pages (133 through 138) illustrate the hardware path(s) involved with the call. This is a valuable trouble- shooting aid; the hardware path and dynamic data structures can be found for a failed call. Figure .AW G174/ is an example of an ISDN Hardware Call Trace. Figure .AW G175/ is an example of an ISDN BRCS Hardware Call Trace. Figure .AW G176/ is an example of a Multipoint DSL Hardware Call Trace. Figure .AW G177/ is an example of an OSPS OPT Hardware Call Trace. Figure .AW G178/ is an example of a PBX DID on SLC(R) Carrier Hardware Call Trace. Refer to 131 - Call Trace Menu display (Figure .AW G172/) for the complete list of call traces that can be invoked (by poke commands) from the 133 through 138 page displays. Also, all available page displays can be invoked from the 133 through 138 page displays. The 139 packet switch call trace page displays the hardware and software information describing a specified packet switch digital service line (DSL). Poke commands are provided on this page display to allow the user to observe the following: o Return to the utility call trace menu page (131). An indicator in the upper left-hand corner of the 139 page display (Figure .AW G179/) directs the user to the 131 menu page. o View the active logical channels associated with the particular port. There are 16 views of this page display. Each view displays 8 active logical channels for the trace. The poke 9XX allows the user to specify which view is to be displayed. An indicator in the upper right-hand corner of the 139 page display identifies the total active logical channel numbers (LCN) to view. The summary information is filled in starting with view 1 of the 139 page display. o Print the entire summary to the ROP. Poke 920 is provided to allow the user to dump the entire trace summary to the ROP. o Hex dump to the ROP of a specific access line control block (ALCB) or the logical channel control blocks (LCCB) associated with the LCN. Poke 930 allows the user to dump two data structures to the ROP (depending on the value of X). a. If X=ALCB, the ALCB associated with the packet call trace is printed on the ROP. b. If X=1-127 (specific LCN), the LCCB associated with the LCN is printed on the ROP. o Hex dump to the ROP of all collected data associated with the trace. Poke 940 allows the user to print the following data on the ROP: a. DCCB -- D-Channel Control Block b. LLCB -- Logical Link Control Block c. ALCB -- Access Link Control Block d. LCCB -- Logical Channel Control Block e. PTSB -- PIDB Time Slot Block f. DPB -- D-Channel Port Block g. PORTLA -- Port Linkage Area. o View the hardware connection of the port. An indicator in the upper right-hand corner of the 139 page display directs the user to the 140 page display where the hardware connection of the trace can be viewed. Figure .AW G179/ shows an example of the 139 page display. The following poke commands are provided on the 139 page display. CMD RESULT 9XX (X=00-08) Next view in sets of 8 LCNs 920 Print entire summary to ROP 930,X (X=LCN|ALCB) Hex dump of specific LCCB (X=LCN) or ALCB 940 Hex dump of all collected data to ROP The purpose of the 140 page display is to show the hardware connections for the packet call trace and circuit switch D- channel call trace. The 140 page display has two versions: 1. The PSU Direct Connect hardware call trace illustrates: o DN or Multipoint DSL o LCEN [LCEN includes the SM number, the line unit (LU) number, the line group (LG) number, and the line card (LC) number.] o PKT (``PKT'' appears in the block where the channel type and number are located indicating the hardware connections are for a packet switch call trace.) o Channel type and number (B1, B2, or D types) o DPIDB number o DPIDB time slot. 2. The PSU Cut-through hardware call trace illustrates: o DN o LCEN (LCEN includes the SM number, the LU number, the LG number, and the LC number.) o Channel type and number (B1, B2, or D type) o PIDB number o PIDB time slot from the ISLU to the DI o PTS number from the DI to the TSI o PTS number from the TSI to the DI o PIDB number and time slot from the TSI to the DI. Figure .AW G180/ is an example of a circuit switched D-Channel trace of a Multipoint DSL. Note: The PDB(ts) abbreviation on the 140 page display actually means protocol handler data bus (PHDB). The PDB(ts) abbreviation appears on the page display because an internal software process is also named PHDB. Figure .AW G181/ is an example of an X.75' packet switched cut-through hardware call trace. Any available displays can be accessed from the 140 page. The purpose of the 141 through 144 display pages is to provide a more detailed summary status of groups of 48 SMs on one display. Displays 141, 142, 143, and 144 are very similar. Each one can display summary status of up to 48 SMs. Page 141 displays status for SMs 1 through 48, Page 142 displays summary status for SMs 49 through 96, Page 143 displays status for SMs 97 through 144, and Page 144 displays summary status for SMs 145 through 192. Each equipped SM has a unique indicator on these displays. Each indicator has three distinct sections: o SM NUMBER: There may be gaps in SM numbering for a particular office. To provide flexibility in office numbering schemes, the SM numbers are not necessarily assigned sequentially. If an SM is not equipped, it is not shown. An example of this is shown in the 141 page example (Figure .AW G182/) by the blank indicators between SM 12 and SM 20, SM 20 and SM 24, etc. o SM TYPE: There is a 3-character acronym to show how an SM is being used. For example, an LSM is a local switching module. o SM STATUS PHRASE: This is a 10-character, maximum, phrase which describes the most significant off-normal condition in the SM. During initialization, the status phrase will give the current initialization progress type. Table .AW TAH/ lists status phrases in order of priority and gives the color and an explanation for each phrase. Included are new phrases which were added with the 5E6 software release (INIT ISOL, HSM STALN, CMP ISOL, HSM ISOL). For detailed information on SM progress markers, see AT&T 235-105-250, System Recovery. If more than one off-normal condition exists in an SM, a ``+'' will appear to the right of the status phrase (SMs 1, 5, and 48 in Figure .AW G182/). A complete list of active off-normal conditions can be output via menu command 900. In addition to this page, the status phrase is shown on all per-SM pages. When a new alarm condition on an SM occurs, the SM indicator will begin flashing. The ALM RLS key will not stop the flashing. The color of the flashing will reflect the new alarm only if the newly recorded condition is of higher or equal priority to the previous condition. To stop the flashing, the craft should display the 1010 page for that SM. There is also a command to retire the flashing for the range of SMs associated with the page being displayed - 999. This is mainly provided for situations such as during installation when SMs are being grown and many SMs are displaying recurrent error conditions. The backlighted note about the DLIs appears whenever an ONTC is out of service or unavailable. The DLIs are under the maintenance control of the ONTCs, thus all DLIs on a side are affected when the ONTC of that side is off-normal. For further details on any SM recovery-related activity or SM inhibits, the craft would enter 1800,X to display the SM X INHIBIT AND RECOVERY CONTROL page. This is the SMs control page for emergency action. For details on circuits out of service or hardware in a particular SM, the craft would enter 1010,X to display the SM X STATUS page. This page can be accessed during the initialization of SM X or if SM X is isolated, but the only status that will fill in are the SM STAT and RELATED PAGES boxes. For details on ONTC circuits out of service, the craft would enter 115 to display the COMMUNICATION MODULE SUMMARY page. In the example of the 141 page shown in Figure .AW G182/, SM 1, which is an LSM, has several off-normal conditions. The ``+'' indicates that there is more than one off-normal condition. For the most critical condition, inhibits are set. Both SM 3 and 10 have circuits out of service. The SM 5, an RSM, has a hash error plus other off-normal conditions. The SM 06, another LSM, is isolated. This indicator would be flashing in the display, which cannot be shown here. The SM 48, another RSM, has a building power alarm plus other off-normal conditions. There is an off-normal condition in ONTC 1 causing all the DLIs on Side 1 to be off-normal. All available displays can be accessed from the 141 through 144 display pages. CMD RESULT 900 The off-normal report is output for the SMs associated with the page (OP:SYSSTAT,SM=a&&b) [,LSM] [,HSM] [,RSM] [,UCL] where a&&b is the range of SMs associated with the page being displayed 999 SM flashing is retired for the range of SMs associated with the page 1010,X SM X STATUS page is displayed 1271 SM 1 - 48 REX SUMMARY page is displayed 1600,SZ SITE Z STATUS page is displayed 1800,X SM X INHIBIT AND RECOVERY CONTROL page is displayed The 150 page display provides a list of nonidle (that is, talking, held, and alerting) subaddress, line card equipment number (LCEN), and channel of a particular directory number/multiline hunt group number (DN/MLHG). A maximum of 16 subaddresses can be assigned per DN or MLHG. All subaddresses, LCENs, and channel numbers sharing a particular DN can be displayed by entering 401,DN,SA=ALL. The status of subaddresses displayed can be determined by the status indicators located at the lower left-hand corner of the 150 page display. If the subaddress is ``ACTIVE,'' the data (that is, subaddress, LCEN, channel), is backlighted in green; if the subaddress is ``ON HOLD,'' the data is backlighted in blue; and if the subaddress is ``IDLE,'' the data is backlighted in white. The ``ON HOLD'' calls can be traced by utility call trace if the SA option is used. Shared analog lines are assigned to subaddress zero. These are marked by an asterisk on the display page. After the 150 page has been populated with the shared call appearance of a DN/MLHG, the data should be identified, for example (00 2-5-15-10-B1) is: 00 = SA (subaddress number), 2 = SM number, 5 = ISLU/RISLU number, 15 = line group, 10 = line card, and B1 = CH (channel number) (indicating the line is in use - active). Concerning shared call appearance (more than one terminal could use the same DN and subaddress), if traced from the subaddress and only one terminal is using the DN and subaddress, the MCC displays the DN version of the 150 page (not the MLHG version). If more than one terminal is using the same DN and subaddress (bridging) at the same time, only the controller is illustrated on the 150 page. However, when the call is traced from the controller, all bridging parties are illustrated on the 133 through 138 page displays. Multiline hunt group call trace uses the 150 page to display the call appearance for a specific multiline hunt group member. The MLHG number is displayed instead of the DN located at the upper middle portion of the 150 page display. The user can implement an MLHG call trace by entering 404,MLHG,SA (SA = subaddress). For more information concerning the call traces implemented, the 150 page display illustrates associated page displays that have more details of the trace. The associated page displays can be identified in the upper right-hand corner of the 150 page display. Figure .AW G183/ shows an example of the 150 page display. The following four poke commands can be used to initiate a trace. o 401,DN,SA=SUBADDRESS (SA = 00 TO 15) - Traces a specific subaddress of a particular DN. o 404,MLHG,SA=SUBADDRESS - Traces a specific subaddress of a particular MLHG. o 401,DN,SA=ALL - Populates the 150 page with all of the nonidle subaddresses, equipment numbers, and channels of a particular DN. o 404,MLHG,SA=ALL - Populates the 150 page with all of the nonidle subaddresses, equipment numbers, and channels of a particular MLHG. The purpose of the 178 page display is to provide pokes for the disk reconfiguration feature and to show any reconfiguration actions that are in-progress. Commands and information provided on the 178 page are useful in the recovery of one or more failed MHDs. Certain automatic disk configuration data from this page is displayed on the 123 page, Disk File System Access. Figure .AW G184/ shows an example of the 178 page in the normal state. Figure .AW G185/ shows an example of the 178 page when a replacement (MHD 14) is being configured for MHD 0. The 178 page provides commands to allow or inhibit automatic disk configuration on one or more MHDs or on the entire office. Commands are also provided to generate a printout of the current configuration, configure a replacement MHD for one that is defective, and normalize the configuration on a per-MHD basis or on the entire office. CMD RESULT 4XX Replacement for MHD XX is configured 6XX Automatic disk configuration is allowed on MHD XX 699 Automatic disk configuration is allowed on entire office 7XX Automatic disk configuration is inhibited on MHD XX 799 Automatic disk configuration is inhibited on entire office 8XX MHD XX is normalized 899 Entire MHD configuration is normalized 900 Spare disk configuration is output The purpose of the 179 page display is to show configuration relations of physical MHDs to logical MHD sets. Also displayed on this page are the MHDs that have been reconfigured, MHDs that are the active system disks, and MHDs that are the spare disks. A list of reconfigured MHDs also appears on 123 page, Disk File System Access. Page 179 shows related MHD(s) for each logical MHD set (for example, duplmhd) defined in the equipment configuration data (ECD). Figure .AW G186/ shows the normal state of Page 179. Figure .AW G187/ shows that MHDs 0 and 14 have been reconfigured. At this time, MHDs 1 and 14 are the system disks and MHDs 0 and 15 are the spare disks. There are no menu commands on the 179 page display. The purpose of the 180 page display is to show configuration relations of physical MHDs to logical MHD sets. Display Page 180 shows related MHD(s) for each logical MHD set (for example, duplmhd or dupmhd) defined in the equipment configuration data (ECD). Figure .AW G188/ shows the normal state of Display Page 180. There are no menu commands on the 180 display page. The 181 through 184 page displays provide off-line switch module processor (SMP) and peripheral pump status plus off-line pump commands for software releases and translations. The off-line status for each equipped (see the following SM number range for each page) is contained in four fields. The ``aaa'' field is the SM type, the ``bbb'' field is the SM number, the ``c'' field is the active side of the SM, and the ``ddddddddd'' field is the off-line SM status phrase. Each page, 181 - 184, is divided into two basic areas. The top area contains commands to control off-line pumping and restore peripherals. The area at the bottom provides off-line pump status on up to 48 SMs or peripherals. The off-line SM status pages consist of four different screens to display the status for up to 192 SMs. These pages are numbered as MCC Page 181, 182, 183, and 184. Each page can display off-line SM status for up to 48 SMs. Page 181 (Figure .AW G189/) displays status for SMs 1-48, Page 182 (Figure .AW G190/) displays status for SMs 49-96, Page 183 (Figure .AW G191/) displays status for SMs 97-144, and Page 184 (Figure .AW G192/) displays status for SMs 145-192. Each equipped SM has a unique status indicator block on these display pages. Each indicator block has four distinct fields, SM type, SM number, active side of SM, and off-line SM status phrase. Status is indicated in the following form, aaabbb,cddddddddd where: aaa = SM type bbb = SM number c = Active side of SM ddddddddd = Off-line SM status phrase. SM type is as follows: LSM (local SM) RSM (remote SM) HSM (host SM) ORM (optically remoted SM) TRM (2-mile optically remoted SM) blank (unknown, default). SM number on page: 181 = Any number in the range 1-48 182 = Any number in the range 49-96 183 = Any number in the range 97-144 184 = Any number in the range 145-192. Active side of SM = 0 or 1. Off-line SM status phrase is one of the following: o OPUMPHLDn: Indicates an off-line pump hold, nth attempt. o OPUMPn: Indicates off-line pumping, nth attempt. o OHASHCKn: Indicates off-line pump hashsum check, nth attempt. o OPUMPFAIL: Indicates failure to pump an off-line SM. o OVRFYn: Indicates off-line verifying nth check for completion. o OVRFIED: Indicates off-line verification is complete. o OVFYFAIL: Indicates that off-line verification failed. o MATE PUMP: Indicates a successful pump or verify. o OPUMPERFn: Indicates off-line pump of peripheral n. o OPERFFAIL: Indicates failure of an off-line peripheral pump. o OPERF OOD: Indicates off-line peripheral is out of date. o ORST: Indicates that a duplex peripheral is restoring. o ORSTFAIL: Indicates failure to restore a peripheral. o STANDBY: Indicates mate is in standby. o MATE OOD: Indicates mate is out of date. o UPDATING: Indicates mate is off-line pumping. During non-off-line pump intervals, these pages will display the status of SM mate memory. The mate memory indications, which are also shown on Page 1800, are STANDBY, MATE OOD, or MATE PUMP. When an SM is being pumped, the status of mate memory on Page 1800 shows UPDATING when the pumping starts. If the pump is successful, the next status indicated is MATE PUMPED or, if it fails, status of the mate memory shows OOD (out of date). If failure occurs during off-line pumping, the SM Off-line Pump System Process retries a maximum of three partial pumps. Examples of MCC Pages 181, 182, 183, and 184 are shown respectively in Figures .AW G189/, .AW G190/, .AW G191/, and .AW G192/. Pages 181 through 184 provide commands to start pumping SMs, stop pumping SMs, start pumping peripherals, restore peripherals, and output off-line pump. All available displays can be accessed from Pages 181 through 184. 2 CMD RESULT (See Note) 2000 Start off-line pump on equipped SMs = 1-192 (ST:OPUMP,SM=1&&192,OFLDISK,VFY,PERF) 200X Start off-line pump on SM = X (ST:OPUMP,SM=X,OFLDISK,VFY,PERF) 20XX Start off-line pump on SM = XX (ST:OPUMP,SM=XX,OFLDISK,VFY,PERF) 2XXX Start off-line pump on SM = XXX (ST:OPUMP,SM=XXX,OFLDISK,VFY,PERF) 3000 Stop off-line pump on SMs = 1-192 (STP:OPUMP,SM=1&&192) 300X Stop off-line pump on SM = X (STP:OPUMP,SM=X) 30XX Stop off-line pump on SM = XX (STP:OPUMP,SM=XX) 3XXX Stop off-line pump on SM = XXX (STP:OPUMP,SM=XXX) 4000 Start off-line pump on peripherals of SMs = 1-192 (ST:OPUMP,SM=1&&192,PERF) 400X Start off-line pump on peripherals of SM = X (ST:OPUMP,SM=X,PERF) 40XX Start off-line pump on peripherals of SM = XX (ST:OPUMP,SM=XX,PERF) 4XXX Start off-line pump on peripherals of SM = XXX (ST:OPUMP,SM=XXX,PERF) 5000 Restore peripherals on SMs = 1-192 (RST:PERF,SM=1&&192) 500X Restore peripherals on SM = X (RST:PERF,SM=X) 50XX Restore peripherals on SM = XX (RST:PERF,SM=XX) 5XXX Restore peripherals on SM = XXX (RST:PERF,SM=XXX) 600X OP OPUMP on SM = X (OP:OPUMP,SM=X) 60XX OP OPUMP on SM = XX (OP:OPUMP,SM=XX) 6XXX OP OPUMP on SM = XXX (OP:OPUMP,SM=XXX) Note: X = 1-9 (Page 181) XX = 10-48 (Page 181) XX = 49-96 (Page 182) XX = 97-99 (Page 183) XXX = 100-144 (Page 183) XXX = 145-192 (Page 184) The 190 display page provides commands to update/restart individual craft processes in lieu of a craft init (15 on the EAI display), which would update/restart all the craft processes. The entire 190 display page consists of commands as follows: o 800 - UPDATE C/D GLOBAL MENU command is used to activate a new menu of the displays and maintenance commands (menu.x). o 801 - UPDATE C/D STATE TRANSLATION command is used to activate a new table of states available for the displays (trantab.x and trantab.xc). o 802 - RESTART ULARP restarts the UNIX system Level Automatic Restart Process. This process controls the order in which UNIX system level processes are started/restarted. o 803 - RESTART CSOP restarts the Coordinator of Spooler Output Processes. This handles the flow of the TTY messages. It directs the messages to the appropriate devices, sorts them, and generates other actions resulting from the messages. o 804 - RESTART RTS restarts the Real Time Status process. This process monitors the status of the units shown on 111/112 - AM/AM PERPH and the SCC, if equipped. It can be used if there is a suspected problem with status updates to Page 111/112. o 805 - RESTART DAP restarts the Display Administration Process. DAP controls the displays. o 806 - RESTART CIA restarts the Critical Indicator Administrator. The CIA interfaces the SUMMARY STATUS INDICATORS on the displays to the Critical Indicator Panel at the SCC, if the SCC is hooked up. o 807 - RESTART POKER(S) causes a new poker to be created for each maintenance display terminal. The poker is the interface from the display terminal to DAP. This command could be used if a single maintenance display terminal is locked out. o 808 - RESTART CFTSHL(S) restarts the craft shell. This can be used if TTY input messages cannot be entered. o 810 - SCC COLOR sets the SCC terminal to color. This command only works from the SCC. If entered from any other terminal, a no good (NG) is returned. o 811 - SCC B/W sets the SCC terminal to black and white. This command, like 810, only works from the SCC. Figure .AW G193/ is an example of the Control/Display page. The entire display is commands. In addition to these, any available paging command can be entered from the 190 display page. CMD RESULT 800 C/D Global Menu is updated 801 C/D State Translation is updated 802 ACP is restarted 803 CSOP is restarted 804 RTS is restarted 805 DAP is restarted 806 CIA is restarted 807 POKER(S) is (are) restarted 808 CFTSHL(S) is (are) restarted 810 SCC terminal is set to color 811 SCC terminal is set to black and white The 191 display page shows operating system resource usage. The 191 display page shows AM resource usage. This page is not updated unless one of the refresh rate menu commands is entered from the master control center (MCC). After a refresh rate is selected, the display will be updated according to the rate and then will time out or can be halted by entering the FREEZE command. The data on the 191 display page can be used to find what real time impact a process has on the system as it is activated. It also shows any resource approaching or at overload. If any overload occurs and requires craft action, there will be corresponding output messages detailing the action to be taken. On color MCCs, the bar graphs on the graphic portion of the page are color coded to show the utilization. The level of utilization colors used on the bar graphs are as follows: o GREEN: For normal utilization o MAGENTA: For heavy, but not overloaded utilization o RED: For any resource approaching overload or at overload. There are four refresh rates available for monitoring resource usage as follows: o FREEZE: No refresh (halt refresh) o 1 SECOND: Refreshes once per second or 20 seconds o 5 SECONDS: Refreshes once every 5 seconds for a maximum of 10 minutes o 30 SECONDS: Refreshes once every 30 seconds for a maximum of 2 hours. Indicators shown under the DISPLAY RATE are as follows: o SPN: Process number (hexadecimal) of the last supervisor process dispatched o SWAPI: Number of segments swapped in since last refresh (0 unless page or page table utilization goes to 100 percent) o SWAPO: Number of segments swapped out since last refresh (0 unless page or page table utilization goes to 100 percent) o STIME: Number of 10-millisecond timer intervals accrued to supervisor processes since last refresh (should be approximately 100 times the display rate) o KTIME: Number of 10-millisecond timer intervals accrued to kernel and special processes since last refresh o KPTIME: Number of 10-millisecond timer intervals accrued to all kernel processes since last refresh. The following resource types are used on the 191 page: o MSG: Message blocks in use o DCT: Number of active processes in the system o SDT: Number of segments in use (must be at least three times the number of active processes) o PDT: Physical pages in use (swapping will occur when all physical pages are in use) o PDT1: Physical pages in use in memory module 1 (These pages are never swapped out and are free only when the process which owns the pages terminates. This field is only displayed on 3B20 machines equipped with the EMM feature.) o PGT: Page tables in use o SSZ: Swappable memory utilization (shows amount of available swap space used) o SDK: Disk swap block utilization (shows amount of available disk swap blocks used). The screen in Figure .AW G194/ is not currently being updated (shown by FREEZE in reverse video). The data in the numeric and graphic indicators shows usage from an earlier display refresh request. CMD RESULT 500 Display refresh is halted 501 Display is refreshed every second for 20 seconds 505 Display is refreshed every 5 seconds for a maximum of 10 minutes 530 Display is refreshed every 30 seconds for a maximum of 2 hours The 197 display page provides status and commands for cutover. Cutover/cutback is the transfer of lines from one switching system to another. When cutover is active, an indicator to the right of the OFFICE STATE indicator will say CUTOVER ACTIVE and be backlighted. On Page 116 - MISCELLANEOUS, the CUTOVER ACTIVE indicator will be backlighted. In the SUMMARY STATUS AREA, the MISC critical indicator will be backlighted. The ENABLE STATE indicator contains one of the following phrases: o NONE o PRECUT o POSTCUT. The OFFICE STATE indicator will contain one of the following phrases: o PRECUT o POSTCUT. The CUTOVER/CUTBACK EXECUTION STATUS indicator has the following possibilities: o MIGRATION COMPLETE o ENABLE CUTOVER FIRST o ENABLE CUTBACK FIRST o ACTIVATE CUTOVER PROGRAM o NO SM'S READY TO MIGRATE o NOT ALL SM'S MIGRATING. Refer to AT&T 235-105-200 for specifics in using this display page. Figure .AW G195/ shows cutover/cutback has been completed. In addition to the following commands, any available paging command can be entered from this display. CMD RESULT 600 Cutover is enabled (EXC:CO:CMD=ENCUT) 601 Cutover is executed (EXC:CO:CMD=CUT) 602 Cutover is aborted (EXC:CO:CMD=ABORT) 700 Cutback is enabled (EXC:CO:CMD=ENCBK) 701 Cutback is executed (EXC:CO:CMD=CUTBK) The SM Page Index page provides an index to the SM and remote switching module/remote integrated services line unit (RSM/RISLU) pages. The 1000 page is an index to the primary SM/RSM/RISLU pages that directly have status reflected on the 1010 - SM X STATUS page. No status is displayed on the 1000 page. The page is divided into two parts. The first part displays all the pages that are valid for local switching modules (LSM), host switching modules (HSM), and RSMs/RISLUs. The second part displays the pages that are only valid for RSMs/RISLUs and remote sites. Some pages shown on the 1000 page reference additional pages that provide more detailed information. These additional pages may not appear on the 1000 page. Most SM pages are specified using an SM number. Some pages, however, are referenced by the site number of a remote site. For these pages (such as the 1600,SZ page), the ``S'' shown on the 1000 page is actually entered as part of the menu command. For example, entering ``1600,S3'' will display the status of RSMs/HSMs at Site 3. For all pages, once an SM page has been displayed for a particular SM, any other page for that SM may be requested without respecifying the SM number. The index shown in Figure .AW G196/ is a listing of the primary SM and SITE maintenance displays for the 5E6 software release. All available paging commands can be entered from this display. 3 LSM and HSM Pages CMD RESULT 1010,X SM X - STATUS page is displayed 102Y,X SM Y - LU X CONCENTRATOR page is displayed, if equipped 103Y,X SM X - LU Y SG 0 page is displayed, if equipped 104Y,X SM X - LU Y SG 1 page is displayed, if equipped 105Y,X SM X - TU Y SG 0 page is displayed, if equipped 106Y,X SM X - TU Y SG 1 page is displayed, if equipped 107Y,X SM X - DCTU Y page is displayed, if equipped 108Y,X SM X - LDSU Y SG 0 AND 1 page is displayed, if equipped 109Y,X SM X - RAF Y page is displayed, if equipped 110Y,X SM X - GDSU Y page is displayed, if equipped 1110,X SM X - ISTF page is displayed, if equipped 112Y,X SM X - DLTU Y page is displayed, if equipped 113Y,X SM X - MSU Y SG 0 page is displayed, if equipped 114Y,X SM X - MSU Y SG 1 page is displayed, if equipped 115Y,X SM X - DCLU Y page is displayed, if equipped 1186,X SM X PSU NETWORK page is displayed 1190,X SM X - MCTSI page is displayed 1200,X SM X - DLI/TMSLNK page is displayed 1280,X SM X - REX STATUS page is displayed 1460,X SM X - DATA LINK DSLS page is displayed, if equipped 170Y SM X ISLU Y NETWORK page is displayed 1800,X SM X - INHIBIT AND RECOVERY CONTROL page is displayed 1900,X SM X - CLNKS page is displayed 4 RSM/RISLU Pages CMD RESULT 1160,X SM X - MISC UNITS page is displayed, if equipped 1170,X SM X - RCLK page is displayed, if equipped 1190,X SM X - MCTSI/RLI page is displayed 1400,X SM X - RSM BLDG/PWR ALARMS page is displayed, if equipped 1420,SZ RISLU BLDG/PWR page is displayed 145Y,X RISLU DLTU Y page is displayed 1600,X SM X SITE STATUS page is displayed via SM number, if equipped 1600,SZ RSM/RISLU SITE STATUS page is displayed 1610 RSM SITE INDEX page is displayed 1615 ORM SITE INDEX page is displayed 1620,SZ RISLU SITE STATUS page is displayed 1630 RISLU SITE INDEX page is displayed The 1010,X display page provides a summary and status of equipped hardware units in the SM and a summary of any miscellaneous activities in the SM. There are five separate versions of the 1010,X page as follows: o Local Switching Module (LSM): The LSM version has an MCTSI summary indicator and indicators for the Operating Service Position System (OSPS) terminal equipment and the RISLU circuits. (See Figures .AW G197/ and .AW G198/ for examples of the LSM version.) o Host Switching Module (HSM): The HSM version has an MCTSI summary indicator and a remote switching module (RSM) indicator box for displaying all RSMs for which the HSM is responsible and the SITE where each of the RSMs is located. No status is given for the RSMs on this page. (See Figure .AW G199/ for an example of the HSM version.) o Remote Switching Module (RSM): The RSM version has an MCTSI/RLI summary indicator, a BLDG/PWR ALARMS indicator (if equipped), the name of the SITE where the RSM is located, and the number of the HSM hosting the RSM. Each RSM has a SITE number from 001 through 174 associated with it. Both LSMs and HSMs are always SITE 000. The SITE number is indicated on every SM page just under the SM Status box. (See Figures .AW G200/ and .AW G201/ for examples of the RSM version.) o Position Switching Module (PSM): The PSM version has an MCTSI summary indicator and a RISLU indicator box for displaying all RISLUs that the PSM is responsible for and the SITE where the RISLUs are located. No RISLU status is given on this page. (Figure .AW G202/ is an example of the PSM version.) o Optically Remoted Module (ORM): The ORM version has an MCTSI summary indicator, a BLDG/PWR ALARMS indicator (if equipped), and the name of the SITE at which the ORM is located. Each ORM has a SITE number from 001 through 174 associated with it. Both LSMs and HSMs are always SITE 000. The SITE number is indicated on every SM page just below the SM Status box. (Figure .AW G203/ is an example of the ORM version.) Every equipped SM has its highest priority status displayed in its SM STAT indicator. This corresponds to the status shown on Pages 141 - 144. The RELATED PAGES box is blank unless there is an off-normal condition in the SM that is not otherwise indicated elsewhere on this page. In some cases, this box shows a page(s) which will give more detailed information about the off-normal condition. The equipped hardware units vary from one SM to the next. The only unit in every SM is the MCTSI. Any equipped unit will be listed in the graphic boxes on the right-hand portion of the display. When an off-normal condition occurs, the indicator for the fault will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for the SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Some RSM/ORM sites do not have the BLDG/PWR ALARMS equipped. If this page is displayed for an RSM/ORM that is at a site which does not have the BLDG/PWR ALARMS equipped, or the BLDG/PWR ALARMS are associated with a different RSM/ORM at the same site, the 1010 page for that RSM/ORM will not show the BLDG/PWR ALARMS box. If the RSM/ORM has the BLDG/PWR ALARMS equipped and if any RSM/ORM alarm is inhibited, the INHIBIT indicator is backlighted. If there is an RSM/ORM BLDG/PWR alarm active, the ALARM indicator will be backlighted. Further information can be found on display 1400 - SM X RSM/ORM BLDG/PWR ALARMS. The PSM is limited by real-time capacity to a maximum of 60 operator positions. A PSM can host up to five RISLUs (loaded to a collective total of 60 operator positions) with one active and one spare T1 span each. This corresponds to 10 PIDBs for RISLUs, plus 2 PIDBs for the PSU shelf, and 3 PIDBs for announcements, for a total of less than 16 PIDBs per TSI. The PSM is not time slot limited. Note that a PSM is a dedicated SM and cannot contain any lines, trunks, service circuits, or test ports. The following hardware items are engineered for the PSM: o PSU o DSU2-RAF o DLTU-RH. A DSL_MAJOR or DSL_MINOR alarm indication is present in the SM STATUS box, and SEE 1460 is present in the RELATED PAGES box when the OSPS terminal equipment is OOS. The 1460-DATA LINK DSLS page display provides the status of the OSPS terminal equipment. The following indicators are applicable to the RISLU equipment on the SM: o The CKT_OOS SM STATUS phrase can refer to the OOS RISLU circuits. o The RISLU UNIT SUMMARY indicator backlights when RISLU circuits are OOS or RISLU fan/fuse alarms are present. o The RISLU digital line trunk unit (DLTU) summary indicator backlights when RISLU digital facility interfaces (DFI) are OOS or carrier group alarms (CGA) are present. o The RISLU SITE BLDG/PWR ALARM indicators backlight if the alarms are off-normal at one or more RISLU sites hosted by a specific SM that monitors RISLU site alarms. If the SM is isolated or initializing, this display is available, but the only status that will fill in reliably is the SM STAT box and the RELATED PAGES box. The only per-SM displays available during these conditions are 1800,X - SM X INHIBITED & RECOVERY CONTROL, 1200,X - SM X DLI/TMSLNK, and 1900,X - SM X CLNKS. Also, 1600,X or 1600,SZ - SITE Z STATUS will be available if at least one of the RSMs at the site is not isolated. Figure .AW G197/ is an example of the LSM version that shows SM 115 status. In this example, the SM STAT box shows that SM 115 is in DSL MAJOR. The ``+'' (following DSL MAJOR) indicates the presence of additional (less important) off-normal conditions. A complete list can be generated and output via the 900 menu command. Additional information on the DSL MAJOR condition is available on the 1460 and 1800 pages as indicated in the RELATED PAGES box. The equipped hardware units are listed in the graphic portion (lower right area) of the display. In this area, an off-normal RISLU condition is reflected by the backlighted DLTU 0 indicator. Figure .AW G198/ is an example of the LSM version. In this example, SM 115 LSM status (DSL_MAJOR) indicates the DSL data link is OOS. Pages 1460 and 1800 are referenced for additional information. Figure .AW G199/ is an example of the HSM version of the SM status display. In this display, the HSM is normal. This HSM is hosting four RSMs located at two different sites. Figure .AW G200/ is an example of the RSM version of the SM status display. In this example, DLTU 0 and MSU 0, SG 0 have some off- normal condition. Also, there is a building/power alarm. Figure .AW G201/ shows the RSM version of the SM status display with no building/power alarms equipped. This SM has an off-normal condition in the remote clock unit and, one or more inhibits are set. The ``+'' in the SM STAT box indicates the presence of additional (less important) off-normal conditions. The user is directed to see Page 1800 for additional information. A complete list can be generated and output via the 900 menu command. Figure .AW G202/ shows the PSM version of the SM status display. The PSM has a RISLU which is equipped with building/power alarms and has a building/power alarm off normal. Also, there is an off- normal state at RISLU site 502. Figure .AW G203/ shows the ORM version of the SM status page. The ORM is equipped with the building/power alarms. The ORM is displaying a HASH-ERR with the MCTSI memory. The ``+'' in the SM STAT BOX indicating the presence of additional (less important) off-normal conditions. Additional information is available on Pages 115 and 1800. A complete list can be generated and output via the 900 menu command. A command is provided to output the off-normal report for the SM for which the 1010,X page is displayed. All available paging commands can be entered from the 1010,X display page. CMD RESULT 900 Output the off-normal report for the SM (OP:SYSSTAT,SM=SM#) The purpose of the 102X,Y page display is to illustrate the status of the equipped line unit (LU) concentrators and A-LINKs. The 102X,Y page has three distinct versions. In each version, the ``X'' equals the line unit number and the ``Y'' equals the switching module number. Each LU (models 1, 2, and 3) has an associated version of the 102X,Y display page. The first version, for LU model 1, is for the regular LU concentrator. The second and third versions, illustrates that each grid is divided into two boards. Status and maintenance commands are available for each board in the grid. The A-LINK indicator is a summary of any out-of-service A-LINKs. This indicator contains either the term OOS and is backlighted (if an A-LINK is OOS) or the term NORM and is not backlighted (all A-LINKs normal). The SM STAT box indicates the presence of an INHIBIT condition. The ``t'' in the SM STAT box indicates the presence of additional (less important) off-normal conditions. A complete list can be generated and output via the 900 menu command. Figure .AW G204/ is an example of the LU model 1 version of the LU concentrator display. Figure .AW G205/ is an example of the LU model 2 version of the LU concentrator display. Figure .AW G206/ is an example of the LU model 3 version. Commands are provided to remove, restore, diagnose, and test (fabric exercise) the LU concentrator grids/grid boards. Also, a command is provided to output a list of all out-of-service A- LINKs. All available page display commands can be entered from the 102X,Y page display. 3 Model 1 Version CMD RESULT 20X Grid X is removed (RMV:GRID=SM#-LU#-X) [,UCL] 30X Grid X is restored (RST:GRID=SM#-LU#-X) [,UCL] 50X Grid X is diagnosed (DGN:GRID=SM#-LU#-X,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 51X Grid X is tested (TST:GRID=SM#-LU#-X,RAW,TLP) [,UCL] [,AUD] [,PH=a|a&&b] a is the diagnostic phase or a&&b is the range of phases to be performed 900 Out of service ALINKs are output (OP:CFGSTAT,SM=SM#,ALINKS) 3 Model 2 and Model 3 Versions CMD RESULT 200X Board 0 of Grid X is removed (RMV:GRIDBD=SM#-LU#-X-0) [,UCL] 201X Board 1 of Grid X is removed (RMV:GRIDBD=SM#-LU#-X-1) [,UCL] 300X Board 0 of Grid X is restored (RST:GRIDBD=SM#-LU#-X-0) [,UCL] 301X Board 1 of Grid X is restored (RST:GRIDBD=SM#-LU#-X-1) [,UCL] 500X Board 0 of Grid X is diagnosed (DGN:GRIDBD=SM#-LU#-X-0,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH-b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 501X Board 1 of Grid X is diagnosed (DGN:GRIDBD=SM#-LU#X-1,RAW,TLP) same options as 500X 502X Board 0 of Grid X is tested (TST:GRIDBD=SM#-LU#-X-0,RAW,TLP) 503X Board 1 of Grid X is tested (TST:GRIDBD=SM#-LU#-X-0,RAW,TLP) 900 Out-of-service ALINKs are output (OP:CFGSTAT,SM=SM#,ALINKS) The purpose of the 103Y,X and 104Y,X display pages is to show status and commands for the equipped line units. The 103Y,X and 104Y,X displays are graphically identical. The differences are page numbers and titles. There are two separate versions of this page. The first version (Figure .AW G207/) is for the regular line unit. This version has GDXCON and maintenance commands for it. The second version (Figure .AW G208/) does not have these commands. The configuration is selected by software. When an off-normal condition occurs, the indicator for the condition will backlight. On 1010,X - SM X STATUS, the indicator for the line unit service group will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted; and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Figure .AW G207/ example is the regular version of the line unit display. The version is selected by system software and has GDXCON and maintenance commands for it. Figure .AW G208/ is the C1LU version of the line unit. Commands are provided to remove, restore, and diagnose the line unit circuits. On the regular version, there also is a switch command for the GDXCON. All available displays can be accessed from this page. 3 Both Versions CMD RESULT 2XX Channel XX is removed (RMV:LUCHAN=SM#-LU#-SG#-XX) [,UCL] 240 COMC is removed (RMV:LUCOMC=SM#-LU#-SG#) [,UCL] 260 GDXACC is removed (RMV:GDXACC=SM#-LU#-SG#) [,UCL] 27X CHBD X is removed (RMV:LUCHBD=SM#-LU#-SG#-X) [,UCL] 28X HLSC X is removed (RMV:LUHLSC=SM#-LU#-SG#-X) [,UCL] 3XX Channel XX is restored (RST:LUCHAN=SM#-LU#-SG#-XX) [,UCL] 340 COMC is restored (RST:LUCOMC=SM#-LU#-SG#) [,UCL] 360 GDXACC is restored (RST:GDXACC=SM#-LU#-SG#) [,UCL] 37X CHBD X is restored (RST:LUCHBD=SM#-LU#-SG#-X) [,UCL] 38X HLSC X is restored (RST:LUHLSC=SM#-LU#-SG#-X) [,UCL] 5XX Channel XX is diagnosed (DGN:LUCHAN=SM#-LU#-SG#-XX,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 540 COMC is diagnosed (DGN:LUCOMC=SM#-LU#-SG#,RAW,TLP) same options as 5XX 560 GDXACC is diagnosed (DGN:LUCOMC=SM#-LU#-SG#,RAW,TLP) same options as 5XX 58X HLSC X is diagnosed (DGN:LUHLSC=SM#-LU#-SG#-X,RAW,TLP) same options as 5XX Regular Version Only CMD RESULT 250 GDXCON is removed (RMV:GDXCON=SM#-LU#-SG#) [,UCL] 350 GDXCON is restored (RST:GDXCON=SM#-LU#-SG#) [,UCL] [,STBY] 450 GDXCON is switched (SW:GDXCON=SM#-LU#) 550 GDXCON is diagnosed (DGN:GDXCON=SM#-LU#-SG#) same options as 5XX The purpose of the 105Y,X and 106Y,X displays is to show status and commands for the equipped trunk units. The 105Y and 106Y displays are graphically identical. The differences are page numbers and titles. When an off-normal condition occurs, the indicator for the condition will backlight. On Page 1010,X SM X STATUS, the indicator for the trunk unit service group will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will backlight; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will backlight and a descriptive phrase of the condition will be written unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will backlight. Figure .AW G209/ shows the trunk unit display for service group 0. The CHBD 2 is currently being diagnosed, which can be determined by the out-of-service transient (OOST). The diagnostic has already been completed on circuits 23 and 22, and they passed (they remain out-of-service family until the entire CHBD is finished). The diagnostic is currently up to circuit 21. Circuit 20 was OOSF before the diagnostics were started. Also, the SM STAT box shows that a circuit in this SM is out of service (CKT OOS). Commands are provided to remove, restore, and diagnose the trunk unit circuits. All available displays can be accessed from this page. 2 CMD RESULT 2XX Circuit XX is removed (RMV:TEN=SM#-TU#-SG#-XX) [,UCL] 280 CDI is removed (RMV:CDI=SM#-TU#-SG#) [,UCL] 285 TAC is removed (RMV:TAC=SM#-TU#-SG#) [,UCL] 29X CHBD X is removed (RMV:TUCHBD=SM#-TU#-SG#-X) [,UCL] 3XX Circuit XX is restored (RST:TEN=SM#-TU#-SG#-XX) [,UCL] 380 CDI is restored (RST:CDI=SM#-TU#-SG#) [,UCL] 385 TAC is restored (RST:TAC=SM#-TU#-SG#) [,UCL] 39X CHBD X is restored (RST:TUCHBD=SM#-TU#-SG#-X) [,UCL] 5XX Circuit XX is diagnosed (DGN:TEN=SM#-TU#-SG#-XX,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 580 CDI is diagnosed (DGN:CDI=SM#-TU#-SG#,RAW,TLP) same options as 5XX 585 TAC is diagnosed (DGN:TAC=SM#-TU#-SG#,RAW,TLP) same options as 5XX 59X CHBD X is diagnosed (DGN:TUCHBD=SM#-TU#-SG#-X,RAW,TLP) same options as 5XX The purpose of the 107Y,X display page is to show status and maintenance commands for the directly connected test unit (DCTU), if equipped. If an off-normal condition occurs in any of the DCTU circuits, the circuit indicator will backlight and have text explaining the nature of the off-normal condition. The DCTU indicator on 1010 - SM X STATUS will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR) if applicable, will be backlighted. Figure .AW G210/ shows all the units in the DCTU are active. Commands are provided to remove, restore, and diagnose the units on the display. All available displays can be accessed from this page. 2 CMD RESULT 2XX DCTU Port XX is removed (RMV:DCTUPORT=SM#-DCTU#-XX) [,UCL] 22X PMU X is removed (RMV:PMU=SM#-DCTU#-X) [,UCL] 230 DCTUCOM is removed (RMV:DCTUCOM=SM#-DCTU#) [,UCL] 240 EAN is removed (RMV:EAN=SM#-DCTU#) [,UCL] 3XX DCTU Port XX is restored (RST:DCTUPORT=SM#-DCTU#-XX) [,UCL] 32X PMU X is restored (RST:PMU=SM#-DCTU#-X) [,UCL] 330 DCTUCOM is restored (RST:DCTUCOM=SM#-DCTU#) [,UCL] 340 EAN is restored (RST:EAN=SM#-DCTU#) [,UCL] 5XX DCTU Port XX is diagnosed (DGN:DCTUPORT=SM#-DCTU#-XX,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 52X PMU X is diagnosed (DGN:PMU=SM#-DCTU#-X,RAW,TLP) same options as 5XX 530 DCTUCOM is diagnosed (DGN:DCTUCOM=SM#-DCTU#,RAW,TLP) same options as 5XX and [,SVG] runs diagnostics on the entire service group, including the demand phases 540 EAN is diagnosed (DGN:EAN=SM#-DCTU#,RAW,TLP) same options as 5XX The purpose of the 108Y,X display is to show status and commands for the equipped LDSUs. There are two separate and distinct versions of the 108Y - LDSU Y SG 0 and 1 page. The first version is the model 1 version (Figure .AW G211/). The model 1 version has LDSUCOMs in each service group and up to eight DSCs in each service group. The second version is the model 2 version (Figure .AW G212/). The model 2 version displays status for the LDSUs in each service group (no LDSUCOMs), displays which slot each is located in, and lists up to seven types of circuits and how many there are (no status is displayed) for each service group. When an off-normal condition occurs, the indicator for the condition will backlight. On Page 1010,X - SM X STATUS, the indicator for the LDSU service group will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Figure .AW G211/ is the display for the model 1 version of the LDSU Y SG 0 and 1 page. In this example, everything is active. Figure .AW G212/ shows the model 2 version of the LDSU Y SG 0 and 1 page. In this display example, both service groups are active and both are located in slot 0. They each have 31 tone generators and 30 tone decoders. Commands are provided to remove, restore, and diagnose the LDSU circuits. All available displays can be accessed from this page. 3 Model 1 Version CMD RESULT 20X LDSUCOM SG X is removed (RMV:LDSUCOM=SM#-X) [,UCL] 21X DSC X SG 0 is removed (RMV:DSC=SM#-DSU#-0-X) [,UCL] 22X DSC X SG 1 is removed (RMV:DSC=SM#-DSU#-1-X) [,UCL] 30X LDSUCOM SG X is restored (RST:LDSUCOM=SM#-X) [,UCL] 31X DSC X SG 0 is restored (RST:DSC=SM#-DSU#-0-X) [,UCL] 32X DSC X SG 1 is restored (RST:DSC=SM#-DSU#-1-X) [,UCL] 50X LDSUCOM SG X is diagnosed (DGN:LDSUCOM=SM#,SG#,RAW,TLP) [,UCL] [,GROW] [,SVG] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 51X DSC X is diagnosed (DGN:DSC=SM#-DSU#-SG#-X,RAW,TLP) same options as 50X except SVG 3 Model 2 Version CMD RESULT 23X LDSU SG X is removed from service (RMV:LDSU=SM#-DSU#-X) [,UCL] 33X LDSU SG X is restored to service (RST:LDSU=SM#-DSU#-X) [,UCL] 53X LDSU SG X is diagnosed (DGN:LDSU=SM#-DSU#-X,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed The 109Y,X display page shows the status and maintenance commands for the Recorded Announcement Function (RAF). The page also indicates the associated memory board(s), its application, and the specific slot where the RAF board is located. There are three types of RAF: dial-through announcement (DTA), announcement (ANN), and coin detecting dial-through announcement (COIN). The types associated with the RAF are listed on the 109Y,X page. An RAF has at least one memory board. The RAF application is indicated with the memory board on the page. Figure .AW G213/ is an example of the 109Y,X display page showing an RAF with DTA and OSPS-DA applications. Commands are provided to remove, restore, and diagnose the RAF connections. Any available paging commands can be entered from this display page. CMD RESULT 200 RAF is removed (RMV:RAF=a-b) 300 RAF is restored (RST:RAF=a-b) 500 RAF is diagnosed (DGN:RAF=a-b,RAW,TLP) The purpose of the 110Y,X display page is to show status and commands for the equipped global digital service units (GDSU). The 110Y page displays status for both GDSU service groups. When an off-normal condition occurs, the indicator for the condition will backlight. On Page 1010,X - SM X STATUS, the indicator for the GDSU service group will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Figure .AW G214/ is the display for GDSU SG 0 and GDSU SG 1. In this example, SG 0, DSC 0 (a universal conference circuit), is out of service. Also, the SM STAT box shows that one circuit of this SM is OOS (CKT OOS). Commands are provided to remove, restore, and diagnose the GDSU circuits. All available displays can be accessed from the 110Y page. 2 CMD RESULT 20X GDSUCOM SG X is removed (RMV:GDSUCOM=SM#-GDSU#-X) [,UCL] 21X DSC X SG 0 is removed (RMV:DSC=SM#-GDSU#-0-X) [,UCL] 22X DSC X SG 1 is removed (RMV:DSC=SM#-GDSU#-1-X) [,UCL] 30X GDSUCOM SG X is restored (RST:GDSUCOM=SM#-GDSU#-X) [,UCL] 31X DSC X SG 0 is restored (RST:DSC=SM#-GDSU#-0-X) [,UCL] 32X DSC X SG 1 is restored (RST:DSC=SM#-GDSU#-1-X) [,UCL] 50X GDSUCOM SG X is diagnosed (DGN:GDSUCOM=SM#-GDSU#-X,RAW,TLP) [,UCL] [,GROW] [,SVG] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 51X DSC X SG 0 is diagnosed (DGN:DSC=SG#-GDSU#-0-X,RAW,TLP) same options as 50X except SVG 52X DSC X SG 1 is diagnosed (DGN:DSC=SM#-GDSU#-1-X,RAW,TLP) same options as 50X except SVG The purpose of the 1110,X display page is to show status and commands for the integrated services test functions (ISTF). Page 1110 displays status for all ISTF 0-3 peripheral units in the given SM and shows status of the services and channels serving each unit. When an off-normal condition occurs, the indicator for the condition will backlight. On Page 1010,X, SM X STATUS, there is exactly one box for an SM that has ISTF units. As a result, the indicator for the ISTF will backlight, and SM X STAT will show CKT OOS. On Page 114, EQUIPPED SM STATUS SUMMARY, the indicator for the SM will be backlighted, for example, SM 1 shows 1L OUT (if X=1). On the appropriate Page 141, 142, 143, or 144, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written unless a more critical condition exists. An example of a descriptive phrase is 1 LSM CKT OOS (if X=1). In the SUMMARY STATUS AREA, the SM critical indicator and the appropriate alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Figure .AW G215/ is an example of the 1110,X page. In this example, ISTF 2 is out of service, 0 channel is in use and 10 channels are available for LOOPBACK, 0 channel is in use and 3 channels are available for XMIT, and 0 channel is in use and 13 channels are available for ISTF 2. The SM 001 STAT shows circuit out of service (CKT OOS) and the SM indicator is backlighted. Commands are provided to remove, restore, and diagnose ISTF circuits. All available page displays can be accessed from Page 1110. CMD RESULT 20X ISTF unit X is removed (RMV:ISTF=SM#-X) [,UCL] 30X ISTF unit X is restored (RST:ISTF=SM#-X) [,UCL] 50X ISTF unit X is diagnosed (DGN:ISTF=SM#-X) [,[RAW] [,UCL] [,GROW] [,TLP] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times test is to be repeated (1-32,767) [,PH-d[&&e]] d is the diagnostic phase or d&&e is the range of phases to be performed The purpose of the 112Y,X display page is to show status and provide maintenance controls for DLTU Y and to report local, remote, and Alarm Indication Signal (AIS) Carrier Group Alarms (CGA). The 112Y,X display page has three separate versions. The first version (Figures .AW G216/ and .AW G217/) is for Local Switching Modules (LSM). The second version (Figures .AW G218/ and .AW G219/) is for Host Switching Modules (HSM). The third version (Figures .AW G220/ and .AW G221/) is for Remote Switching Modules (RSM). All three versions have commands to remove, restore, and diagnose DFIs and to remove and restore FACs. The second and third versions have an additional command to test FACs. If the RSM is equipped with any inter-RSM Communication Link Digital Facilities Interfaces (CDFI), commands to remove and restore Remote Communication Links (RCL) will also be added. The DLTU provides direct interfaces to T1 lines. The 112Y,X page is designed into three sections. The first section displays DFI specific information, the second shows T1 Facility 0 information, and the third shows T1 Facility 1 information. When an off-normal condition occurs in a DFI, the DFI indicator will backlight. When a CGA occurs, an indicator appears in the CGA column associated with the DFI. The indicator contains the letter L, R, or A (for local, remote, or AIS, respectively). If one or more off-normal condition is present on this display, the DLTU Y indicator on Page 1010,X - SM X STATUS is backlighted. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. The HSM and RSM versions have information on the DFI displayed in the FAR END column which shows the connection at the ``other'' end. Included will be the SM number, the DLTU number, the DFI number, and the FAC number within the DLTU. The HSM version also has two lines which appear in a box near the top of the display. The first line is labeled RSM -> and will list all RSMs hosted by the HSM for which the page is being displayed. The second line is labeled AT SITE -> and will show the sites of the RSMs listed on the first line. In the HSM and RSM versions, the DFI(s) carrying the control time slot is shown by an (*). In the RSM version, the DFI receiving reference timing is shown by an (&). The LSM version shows neither control time slot nor receive reference timing. Figure .AW G216/ is an example of the LSM Version of the 112Y,X Page which shows the TDFI 5 is out of service and there are CGAs in the group associated with TDFI 3, Facility 0, and TDFI 2, Facility 1. Figure .AW G217/ is an example of the LSM Version of the 112Y,X Page for a DLTU with only one T1 Facility. Figure .AW G218/ shows an example of the HSM version of the DLTU display. In this example, the HSM hosts RSM 192 at SITE 234 and RSM 124 at SITE 301. The HDFI 1 and HDFI 3 are carrying control time slots (*). Figure .AW G219/ is an example of the HSM version of the DLTU display with only one T1 Facility. Figure .AW G220/ shows the RSM version of the DLTU display. In this example, RDFI 4 is OOS and a CGA is associated with RDFI 2, Facility 1. Also, the RCL associated with CDFI 5 is out-of- service family. The RDFI 1 and RDFI 3 are carrying control time slots (*). The RDFI 1 and RDFI 2 are receiving reference timing (&). Figure .AW G221/ shows the RSM version of the DLTU display with only one T1 Facility. All three versions, LSM, HSM, and RSM, have commands to remove, restore, and diagnose DFIs and to remove and restore FACs. The HSM and RSM versions have an additional command to test FACs. In addition, any available paging command can be entered from this display. LSM Version CMD RESULT 20XX DFI XX is removed (RMV:DFI=SM#-DLTU#-XX) [,UCL] 21XXY T1FAC Y of DFI XX is removed (RMV:FAC=SM#-DLTU#-XX-Y) [,UCL] 30XX DFI XX is restored (RST:DFI=SM#-DLTU#-XX) [,UCL] 31XXY T1FAC Y of DFI XX is restored (RST:FAC=SM#-DLTU#-XX-Y) [,UCL] 50XX DFI XX is diagnosed (DGN:DFI=SM#-DLTU#-XX,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 4 HSM Version CMD RESULT 20XX DFI XX is removed (RMV:DFI=SM#-DLTU#-XX) [,UCL] 21XXY T1FAC Y of DFI XX is removed (RMV:FAC=SM#-DLTU#-XX-Y) [,UCL] 30XX DFI XX is restored (RST:DFI=SM#-DLTU#-XX) [,UCL] 31XXY T1FAC Y of DFI XX is restored (RST:FAC=SM#-DLTU#-XX-Y) [,UCL] 50XX DFI XX is diagnosed (DGN:DFI=SM#-DLTU#-XX,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 51XXY T1FAC Y of DFI XX is tested (TST:FAC=SM#-DLTU#-XX-Y) [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 4 RSM Version CMD RESULT 20XX DFI XX is removed (RMV:DFI=SM#-DLTU#-XX) [,UCL] 21XXY T1FAC Y of DFI XX is removed (RMV:FAC=SM#-DLTU#-XX-Y) [,UCL] 22XXY RCL XX of FAC Y is removed (RMV:RCL=SM#-DLTU#-XX-Y) [,UCL] 30XX DFI XX is restored (RST:DFI=SM#-DLTU#-XX) [,UCL] 31XXY T1FAC Y of DFI XX is restored (RST:FAC=SM#-DLTU#-XX-Y) [,UCL] 32XXY RCL XX of FAC Y is restored (RST:RCL=SM#-DLTU#-XX-Y [,UCL] 50XX DFI XX is diagnosed (DGN:DFI=SM#-DLTU#-XX,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 51XXY T1FAC Y of DFI XX is tested (TST:FAC=SM#-DLTU#-XX-Y) [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed The purpose of the 113Y/114Y,X page is to show units equipped, to show status, and to provide maintenance commands for MSU X and multiple MSU X. The 113Y/114Y,X page has two separate versions. The first version (Figure .AW G222/) has one metallic test interface bus access (MTIBAX), four metallic access buses (MAB), and up to sixteen metallic service circuits. The second version (Figure .AW G223/) is the modular Metallic Service Unit (MSU) version and has four MTIBAXs, sixteen MABs, and up to thirty-two metallic service circuits. When an off-normal condition occurs in any MSU circuit, the circuit indicator will backlight. On Page 1010,X - SM X STATUS, the MSU Y SG 0 or SG 1 indicator will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Figure .AW G222/ shows the regular version of the MSU display. This example shows some of the typical MSU circuits which can be equipped on an SM. There are no off-normal conditions. Figure .AW G223/ shows the modular MSU version of the MSU display page. There are no off-normal conditions in this example. Commands are provided to remove, restore, and diagnose various MSU circuits. All available displays can be accessed from the 113Y/114Y,X page. 3 Regular Version CMD RESULT 2XX MAB XX is removed (RMV:MAB=SM#-MSU#-SG#-XX) [,UCL] 220 MSUCOM is removed (RMV:MSUCOM=SM#-MSU#-SG#) [,UCL] 221 PROTO is removed (RMV:PROTO=SM#-MSU#-SG#) [,UCL] 240 MTIBAX 0 is removed (RMV:MTIBAX=SM#-MSU#-SG#-0) [,UCL] 20XX Circuit XX is removed (RMV:CKT=SM#-MSU#-SG#-XX) [,UCL] 3XX MAB XX is restored (RST:MAB=SM#-MSU#-SG#-XX) [,UCL] 320 MSUCOM is restored (RST:MSUCOM=SM#-MSU#-SG#) [,UCL] 321 PROTO is restored (RST:PROTO=SM#-MSU#-SG#) [,UCL] 340 MTIBAX 0 is restored (RST:MTIBAX=SM#-MSU#-SG#-0) [,UCL] 30XX Circuit XX is restored (RST:CKT=SM#-MSU#-SG#-XX) [,UCL] 5XX MAB XX is diagnosed (DGN:MAB=SM#-MSU#-SG#-XX,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 520 MSUCOM is diagnosed (DGN:MSUCOM=SM#-MSU#-SG#,RAW,TLP) Same options as 5XX 521 PROTO is diagnosed (DGN:PROTO=SM#-MSU#-SG#,RAW,TLP) Same options as 5XX, except GROW 540 MTIBAX 0 is diagnosed (DGN:MTIBAX=SM#-MSU#-SG#-0,RAW,TLP) Same options as 5XX, except GROW 50XX Circuit XX is diagnosed (DGN:CKT=SM#-MSU#-SG#-XX,RAW,TLP) Same options as 5XX, except GROW Modular MSU Version CMD RESULT 24X MTIBAX X is removed (RMV:MTIBAX=SM#-MSU#-SG#-X) [,UCL] 34X MTIBAX X is restored (RST:MTIBAX=SM#-MSU#-SG#-X) [,UCL] 54X MTIBAX X is diagnosed (DGN:MTIBAX=SM#-MSU#-SG#-X,RAW,TLP) Same options as 5XX, except GROW The purpose of the 115Y,X page is to show status summary and provide commands for the SLC Carrier DCLU SG 0 and 1 SDFIs, if equipped. If an off-normal condition occurs in any of the DCLU SDFI circuits, the circuit indicator will backlight and have text explaining the nature of the off-normal condition. The DCLU indicator on Page 1010 will backlighted. On Page 114, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (for example, MINOR) will backlight. There are summary indicators for each of the associated RTs. Figure .AW G224/ shows all the SDFI units in SG 1 are active. The SG 0 has two OOS SDFIs (4 and 6). These are both connected to RT 1, and the RT 1 indicator reflects the OOS condition. The second number in the RT box (4768) is the subscriber loop carrier identification (SID). Commands are provided to remove, restore, and diagnose the equipped units. Also provided are paging commands for the associated RTs. 2 CMD RESULT 2XX DCLU SDFI XX is removed (RMV:SDFI=SM#-DCLU#-XX) [,UCL] 23X DCLU SG X is removed (RMV:DCLU=SM#-DCLU#-X) [,UCL] 3XX DCLU SDFI XX is restored (RST:SDFI=SM#-DCLU#-XX) [,UCL] 33X DCLU SG X is restored (RST:DCLU=SM#-DCLU#-X) [,UCL] 5XX DCLU SDFI XX is diagnosed (DGN:SDFI=SM#-DCLU#-XX,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH =b|b&&c]] b is the diagnostic phase or b&&c is the range of phases to be performed 53X DCLU SG X is diagnosed (DGN:DCLU=SG#-DCLU#-X,RAW,TLP) same options as 5XX 131X DCLU X RT 1 page is displayed 132X DCLU X RT 2 page is displayed 133X DCLU X RT 3 page is displayed 134X DCLU X RT 4 page is displayed 135X DCLU X RT 5 page is displayed 136X DCLU X RT 6 page is displayed The purpose of the 1160,X page display is to provide status and menu commands for miscellaneous hardware units in the remote switching module (RSM) and optically remoted module (ORM). The 1160,X page display (Figure .AW G225/) contains any miscellaneous units in an RSM/ORM which do not belong on any other per-SM page. Presently, the only unit contained on this page is the alarm and status circuit (ASC). If the RSM has been retrofitted, the indicator and commands will refer to the Remote Alarm Unit instead of the ASC. When an off-normal condition occurs, the indicator for the fault will backlight. The MISC indicator on Page 1010,X - SM X RSM/ORM STATUS will backlight. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and a descriptive phrase of the condition will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. Commands are provided to remove, restore, and diagnose any miscellaneous units which appear on the 1160,X page. CMD RESULT 200 Remove the Alarm and Status Circuit from service (RMV:ASC SM#) [,UCL] 300 Restore the Alarm and Status Circuit to service (RST:ASC SM#) [,UCL] 500 Diagnose the Alarm and Status Circuit (DGN:ASC SM#) The purpose of the 1170,X display page is to show status and provide maintenance commands for the remote clock, remote clock oscillator, remote clock cross-couples, remote clock oscillator cross-couples, and remote clock references. The 1170X page is only available on remote switching modules (RSM) and only on RSMs that are equipped with a remote clock (RCLK). The remote clock cross-couples (RCXC) show the link status between the two RCLKs. The remote clock oscillator cross-couples (RCOXC) show the link status between the remote clock oscillators (RCOSC) and the RCLKs. Only one reference per side can be in the active state at one time. The rest of the equipped references on that side will be in the standby state if they are not OOS. The RCLK mode is displayed in the RCLK indicators. There are four RCLK modes: o FAST: This is used to obtain initial synchronization with the reference signal. The RCLK is scanning the incoming synchronization signal from the HSM at an accelerated rate. o NORM: This mode means the T1 umbilical to the host SM (HSM) is up and the RCLK has obtained synchronization from the HSM. o HOLD: The holdover mode is used when synchronization is lost. This is an off-normal mode. o FREE: The free mode indicates initialization of an RCLK with no good reference signal. This is an off-normal mode. Figure .AW G226/ shows an example of the 1170,X display page in which RCLK 1 is out of service. This caused RCXC 0, RCXC 1, RCOXC 1, and RCREF 1 and 2 on SIDE 1 to be out-of-service family of equipment (OOSF). It also caused RCOSC 1 to go to standby (STBY) (if not already standby). Commands are provided to remove and restore the RCLK, RCOSC, RCXC, RCOXC, and RCREF, to diagnose the RCLKs, and to switch the RCLKs and the RCOSCs. All available displays can be accessed from the 1170X page. 2 CMD RESULT 20X RCLK X is removed from service (RMV:RCLK=SM#-X) [,UCL] 21X RCOSC X is removed from service (RMV:RCOSC=SM#-X) [,UCL] 22X RCXC X is removed from service (RMV:RCXC=SM#-X) [,UCL] 23X RCOXC X is removed from service (RMV:RCOXC=SM#-X) [,UCL] 24X RCREF X is removed from service (RMV:RCREF=SM#-X) [,UCL] 30X RCLK X is restored to service (RST:RCLK=SM#-X) [,UCL] [,STBY] 31X RCOSC X is restored to service (RST:RCOSC=SM#-X) [,STBY] 32X RCXC X is restored to service (RST:RCXC=SM#-X) 33X RCOXC X is restored to service (RST:RCOXC=SM#-X) [,STBY] 34X RCREF X is restored to service (RST:RCREF=SM#-X) [,ACT | STBY] 403 RCLK is switched (SW:RCLK=SM#) 41X RCOSC X is switched (SW:RCOSC=SM#-X) 50X RCLK X is diagnosed (DGN:RCLK=SM#-X,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed The purpose of Page 118Y,X (Y = shelf 0-5) is to provide status and maintenance commands for PHs, hardware type of PHs, status of channel groups, type of channel groups, and assignment of channel groups to PHs. The PSU Shelf MCC page display (one per PSU shelf) provides two tables. The first table (PSUPH ASSIGNMENT STATUS) contains the 16 individual PHs with their status. The second table (CHANNEL GRP SUMMARY) contains the corresponding channel group type. The PH status data of each of the PSU Shelf pages supplies the PH status summary of the PSU Network display (1186). The PHs serving channel groups are marked active (ACT). The PHs that are able to provide service but are not serving a channel group are marked standby (STBY). The PHs that are removed from service are not available as spares and are marked out of service (OOS). The PHs that are partially faulty may be marked degraded (DGRD), when there are no standby PHs, rather than being removed. This allows the PH to be of partial service to its channel group. For PHs that are out of service or degraded, the PH shelf summary is marked DGRD on the PSU Network page. If possible, the channel groups of OOS PHs are moved to serviceable PHs. When the supply of spare PHs is exhausted, a channel group associated with the OOS PH is removed from the PSUPH Assignment Status table, and the Channel Group number and type on the Channel Group Summary table is backlighted. The shelf of that PH, in the PSUPH Status Summary box (on the PSU Network page), is marked DGRD and the entry of how many channel groups are not being serviced is incremented. Any other state displayed in PH status locations is required for a removable, diagnosable, growable, and inhibitable individual unit. The appropriate peripheral status block of the SM on the SM Status page is marked with PSU. When any portion of the PSU is OOS, the block is backlighted. If the status reported on the SM Status page or on any of the PSU display pages changes while being displayed, the appropriate indicators are updated with changed status. The 118Y,X page (Figure .AW G227/) is divided into three basic areas. The ``CHANNEL GRP SUMMARY'' block at the right side of the display indicates the channel group number, PH hardware type required by the channel group, and channel group type which can be one of the following: o DSLG2 - Used for all Basic Digital Subscriber Line (DSL) and Extended DSL (EDSL) Applications (requires PH type 2) o ISM2 - Inter-SM Packet Switching (requires PH type 2) o TRK2 - Inter-Switch Packet Trunks (requires PH type 2) o X75P2 - X.75' trunks (requires PH type 2) o MIXED2 - More than one type of the application on a logical PH (requires PH type 2). The ``PSUPH ASSIGNMENT STATUS'' block in the middle of the page indicates the PH status, PH hardware type, and channel group assignment to each PH. The hardware equipage in a given PSU is designated by PH type. When equipped, a PH is ACT (active) or STBY (standby). The third area of this display contains the ``SM STAT'' indicator block (with SITE number). Also, below the SM status block, a list of commands exists for management of the PSUPH maintenance. Commands are provided to remove, restore, diagnose, and switch PHs shown on this page. The restore and switch commands also have a group (GRP) option that allows assignment of a specified channel group. The GRP option is only allowed with the switch command when switching from a standby (STBY) PH to an active (ACT) PH. The STBY PH is the one specified in the switch command, and the channel group of the ACT PH is specified in the GRP option (for example, SW:PSUPH=a-0-0-b,GRP=c, where PH number b is a STBY PH and GRP c is assigned to an ACT PH). When restoring PHs, the GRP option can be used to assign a specified channel group to the PH being restored (for example, RST:PSUPH=a-0-0-b,GRP=c, where PH number b is OOS, STBY or ACT, and GRP c is a channel group). If the channel group specified cannot be switched or restored to PH, the command will fail and a message will print indicating why the command failed. Commands available for control of the multiple protocol handlers are as follows: CMD RESULT 2XX Remove PSUPH XX (RMV:PSUPH=a-0-b-XX) 3XX Restore PSUPH XX (RST:PSUPH=a-0-b-XX) 4XX Switch PSUPH XX (SW:PSUPH=a-0-b-XX) 5XX Diagnose PSUPH XX (DGN:PSUPH=a-0-b-XX, RAW,TLP) The 1186,X page display provides the current PSU status, the PSUCOM status, and the PH shelf status summary. The PSU Network page display simultaneously shows the state of both PSUCOMs and a status summary of the PHs per PSU shelf. The PSUCOM is composed of the Control Fanout (CF), and each Data Fanout (DF) and Protocol Fanout (PF) of the equipped shelves of the same side. The PSUCOM can be removed, restored, or switched as a single entity, and the status is noted on the MCC as a duplex SM peripheral controller. The status summary of the PHs on this page is on a shelf basis, because any sparing of the PHs is performed on a shelf basis. When any PH is removed from service or degraded, this page has the shelf of its residence marked degraded. If the shelf should have more PHs removed than the shelf has spares to take the place of the PHs that are serving channel groups, the shelf is marked degraded and the count of channel groups not being serviced is displayed. The possible states of the PH shelves can be ``normal'' (all equipped PHs in service when the shelf is equipped), ``degraded,'' ``unequipped,'' and ``growth.'' The PSUPH SUMMARY indicator box provides status for a maximum of 16 PHs/shelves (indicating 1 spare PH/shelf). Figure .AW G228/ shows an example of the 1186,X page display. Commands are provided to remove, restore, diagnose, and switch PSUCOMs. Also any PSU shelf and any available paging commands can be accessed from this page. In the following commands, a = SM number. CMD RESULT 200 Removes PSUCOM 0 (RMV:PSUCOM=a-0-0) 201 Removes PSUCOM 1 (RMV:PSUCOM=a-0-1) 300 Restore PSUCOM 0 (RST:PSUCOM=a-0-0) 301 Restore PSUCOM 1 (RST:PSUCOM=a-0-1) 500 Diagnose PSUCOM 0 (DGN:PSUCOM=a-0-0,RAW,TLP) 501 Diagnose PSUCOM 1 (DGN:PSUCOM=a-0-1,RAW,TLP) 400 Switch control and state of active and standby PSUCOM (SW:PSUCOM=a-0) 118X Display PSU shelf X The purpose of the 1190,X page display is to show status and provide maintenance commands for the module controller time slot interchanger (MCTSI ), dual link interface (DLI), remote link interface (RLI), and bootstrapper (BTSR). The 1190,X page has two separate and distinct versions. The first version is for local switching modules (LSM) and host switching modules (HSM). This version shows DLIs). The second version is for remote switching module (RSM) and optically remoted module (ORM). The RSM version has RLIs instead of DLIs. When an off-normal condition occurs, the indicator for the condition will backlight. On Page 1010,X, the MCTSI (MCTSI/RLI) indicator will backlight. On Page 114, the indicator for the SM will backlight; and on the appropriate 141, 142, 143, or 144 page, the indicator for the SM will be backlighted, and a phrase describing the problem will be written, unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. If the SM is isolated or initializing and this display is requested, it will display, but only the status of the DLIs will fill in and the SM X STAT indicator will say ISOLATED. The DLI status data is maintained in the AM and is available for display. The MCTSI, RLI, and bootstrapper (BTSR) status data is stored in the SM; and since it is isolated, the data cannot be accessed. The DLI status indicator block is divided into two sections: one for DLI status and the other is used to identify the presence of transmission rate converter unit (TRCU) hardware. The TRCU portion of the indicator block does not indicate alarm status. Bootstrapper Information Poke commands for BTSR (for example, 202 BTSR) are rejected if the SMs are equipped with the SMP20 processor. The SMP20 processor is also referred to as the module controller/time slot interchange model 2 (MCTU2). The poke commands for BTSR on the 1190,X page are applicable only to non-SMP20 SMs. The BTSR status indicator block is not displayed on the 1190,X page when the SM is equipped with the SMP20 processor. Therefore, the BTSR status indicator block is only displayed for non-SMP20 processors (for example, SMP1/SMP12). Figure .AW G229/ is an example of the regular version of the MCTSI display which shows DLI 1 out-of-service family of equipment, due to ONTC 1 being unavailable. Figure .AW G230/ is an example of the ORM version of the MCTSI display. Commands are provided to remove, restore, and diagnose the MCTSI, BTSR, DLIs, and RLIs, to switch the MCTSI and RLI, and to force active the MCTSI. Any available paging commands can be entered from the 1190,X page. 2 CMD RESULT 20X MCTSI X is removed (RMV:MCTSI=SM#-X) [,UCL] 202 BTSR is removed (RMV:BTSR=SM#) [,UCL] 21X DLI X is removed (RMV:DLI=SM#-X) [,UCL] 30X MCTSI X is restored (RST:MCTSI=SM#-X) [,UCL] [,STBY] 302 BTSR is restored (RST:BTSR=SM#) [,UCL] 31X DLI X is restored (RST:DLI=SM#-X) [,UCL] 50X MCTSI X is diagnosed (DGN:MCTSI=SM#-X,RAW,TLP) [,UCL] [,GROW] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 502 BTSR is diagnosed (DGN:BTSR=SM#,RAW,TLP) Same options as 50X 51X DLI X is diagnosed (DGN:ONTC=X,DLI,SM#,RAW,TLP) [,UCL] Same options as 50X 40X MCTSI X is forced active (SET:MCTSI=SM#-X,FRC) 402 MCTSI force is cleared (CLR:MCTSI=SM#,FRC) 403 MCTSI is switched (SW:MCTSI=SM#) The purpose of the 1200,X page is to show status for the DLIs and the TMSLNKs that are connected to each ONTCCOM on a per-SM basis and to provide maintenance commands for the DLIs. The 1200,X page has two separate and distinct versions. The first version is for offices with CM2 hardware, and the second is for offices with CM1 hardware. The difference between the two versions is the note at the lower left of the display defining ONTCCOM. In CM2, an ONTCCOM does not have an LI as part of its hardware. Also provided on the 1200,X page is a view of the DLIs and the TMSLNKs connecting a particular SM to the ONTCs. It shows the status of ONTCCOMs 0 & 1, the TMSLNKs for the particular SM and their status, and the status of the DLIs for the SM. The 1200,X page indicates the presence of the transmission rate converter unit (TRCU) for ORM. Alarm status of the TRCU hardware is not indicated on the 1200,X page. However, if a DLI goes OOS, the TRCU hardware may be faulty. Look on the ROP to see if the TRCU hardware appears on the suspected faulty equipment list. Figure .AW G231/ is the CM2 version of the DLI/TMSLNK display. This example shows ONTCCOM 1 unavailable forced removed (UNV) resulting in DLI 1 and TMSLNKs 14 and 15 for side 1 out-of- service family of equipment (OOSF). The ONTCCOM 0 is degraded- forced (DGRF). Figure .AW G232/ is the CM1 version of the DLI/TMSLNK display. In this example, ONTCCOM 0 is degraded (DGR) minor and ONTCCOM 1 is active (ACT) major. The DLI 0 is unavailable power (UNVP) causing the 0 side TMSLNKs 14 and 15 to be out-of-service family of equipment (OOSF). The SM 6 is isolated. Figure .AW G233/ is an example of the CM1 version of the 1200,X page that shows the TRCU. Commands are provided for removing, restoring, diagnosing, and outputting the configuration status for the DLIs for the SM this page is being displayed for. All available display commands can be entered from the 1200,X page display. CMD RESULT 200 DLI 0 is removed 201 DLI 1 is removed 300 DLI 0 is restored 301 DLI 1 is restored 500 DLI 0 is diagnosed 501 DLI 1 is diagnosed 900 Status of DLI 0 is output 901 Status of DLI 1 is output The purpose of the 1209 display page is to show maintenance states for ONTC 0 and 1 and provide maintenance commands for the ONTCs and ONTCCOMs and hardware check status for ONTC 0 and 1. The 1209 display page has two separate versions. The first version (Figure .AW G234/) is for offices with CM2 hardware. The second version (Figure .AW G235/) is for offices with CM1 hardware. The difference between the two versions is the note at the lower left of the display defining ONTCCOM. In CM2, an ONTCCOM does not have a link interface (LI) as part of its hardware. Fabric update is the updating of the intermodule communication paths between TMS links. This is accomplished by writing in the fabric (FAB) random access memories (RAM) of the TMS, on a per time slot basis, information stored in AM memory. When the FAB update is in progress, the FAB update indicator for the side that is being updated will appear and be backlighted above the appropriate ONTC. Figure .AW G234/ is the CM2 version of the ONTC display. This example shows ONTC 1 unavailable, ONTC 0 is degrade forced, and FAB update is in progress on ONTC 0. Figure .AW G235/ is the CM1 version of the ONTC display. In this display, ONTC 0 is degraded minor and ONTC 1 is active major. The ONTC 0 has its hardware checks inhibited and FAB update is in progress on ONTC 0. Commands are provided for removing, restoring, diagnosing, and outputting the configuration status for the ONTCs and the ONTCCOMs for inhibiting, allowing, and switching the ONTCs and for forcing the ONTCCOMs. All available display commands can be entered from the 1209 display page. 2 CMD RESULT 60X Hardware Checks are inhibited for ONTC X (INH:HDWCHK,ONTC=X) 70X Hardware Checks are allowed for ONTC X (ALW:HDWCHK,ONTC=X) 20X ONTC X is removed (RMV:ONTC=X) [,UCL] 21X ONTCCOM X is removed (RMV:ONTCCOM=X) [,UCL] 30X ONTC X is restored (RST:ONTC=X) [,UCL] 31X ONTCCOM X is restored (RST:ONTCCOM=X) [,UCL] Note: if UCL option is used on an in-service ONTCCOM that has any child units (DLIs, TMSLNKs) OOS, those OOS child units will be restored. 50X ONTC X is diagnosed (DGN:ONTC=X,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 51X ONTCCOM X is diagnosed (DGN:ONTCCOM=X,RAW,TLP) [,UCL] Same options as 50X Note: Implicitly provides status output for all child DLIs/TMSLINKs. 90X Status of ONTC X is output (OP:CFGSTAT,ONTC=X) 91X Status of ONTCCOM X is output (OP:CFGSTAT,ONTCCOM=X) The purpose of the 1210 display page is to show cross-couples between MI/NC 0 and 1, to show the network clock mode, and to provide maintenance commands. The 1210 display page has two separate versions. The first version (Figure .AW G236/) is for offices with CM2 hardware. The second version (Figure .AW G237/) is for offices with CM1 hardware. Status shown for an MI/NC is actually the status of the ONTCCOM (MI/NC/TMS - CM2 or MI/LI/NC/TMS - CM1), side 0 or 1. There is no separate status for the MI/NC (MI/LI/NC - CM1). In the CM2 version, the NC XCs (network clock cross-couples) show the link status between the two NCs. There is a note at the lower left of the display defining ONTCCOM as MI/NC/TMS (no LI). The CM1 can be equipped with a network clock model 1 (NC1) or network clock model 2 (NC2). The NC1 version shows the PRIMARY and SECONDARY T1 carriers and the reference status. Also, there is an indicator showing the status of the LI and showing connections from LI 0 to LI 1 and there is a note at the lower left of the display defining ONTCCOM which includes the LI (MI/LI/NC/TMS). The NC2 version shows a summary status of the network clock references, the network clock oscillators, and oscillator cross-couples with the SEE PAGE 1211 indicator. In the CM2 version, only the NC2 version can be used and the network clock cross-couples show the link status between the two NCs. Below the MI/NC indicators on the display, there are indicators which show the network clock modes. The modes which can be shown are as follows: o FAST: The fast mode is used to obtain initial sync with the reference signal. This would be considered a normal mode. o NORM: After synchronization is obtained, the network clock goes into the norm mode. The norm mode is almost the same as fast, except the tolerance for deviation from the reference signal is narrowed to reduce error. o HOLD: The holdover mode is used when synchronization is lost. This is an off-normal mode. o FREE: The free mode indicates initialization of the NC with no good reference signal. This is also an off-normal mode. o OOS: The OOS (out-of-service) mode is also an off-normal mode. The mode is OOS whenever and only whenever the NC is OOS. When an off-normal condition occurs with the T1 carriers or NC XCs, the MI/NC 0 (MI/LI/NC 0 - CM1) or MI/NC 1 (MI/LI/NC 1 - CM1) indicator backlights on Page 115. This in turn causes the CM indicator in the SUMMARY STATUS AREA to backlight. The alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. Figure .AW G236/ is the CM2 version which shows MI/NC 1 out of service. The MI/NC status is actually the ONTCCOM status. No separate status is maintained for the MI/NCs. The SEE PAGE 1211 is also backlighted to indicate something off-normal on the 1211 page and indicates that this office has a network clock model 2. Figure .AW G237/ shows the CM1 version with MI/LI/NC 0 degraded. The MI/LI/NC status is actually the ONTCCOM status. No separate status is maintained for the MI/LI/NCs. This office is equipped with an NC 1, indicated by the PRIMARY/SECONDARY references on the display. Since the MI/NC (MI/LI/NC - CM1), and TMSs function as a group (ONTCCOM), maintenance commands on this display (remove, restore, force active, and configuration status output) are for the ONTCCOM with the exception of the diagnose commands for the MIs and NCs (and LIs for CM1). Also, there are remove, restore, configuration status output, inhibit, and allow commands for the NC XCs, and a switch command for the ONTC. All available page commands can be entered from the 1210 display page. 3 CM2 Version CMD RESULT 20X ONTCCOM X is removed (RMV:ONTCCOM=X) [,UCL] 21X Network Clock Cross-Couple X is removed (RMV:NCREF,XC=X) 30X ONTCCOM X is restored (RST:ONTCCOM=X) [,UCL] [,MAJOR/MINOR] 31X Network clock Cross-Couple X is restored (RST:NCREF,XC=X) 40X ONTCCOM X is forced active (RST:ONTCCOM=X,FRC) 402 ONTCCOM force is cleared (CLR:FRC,ONTCCOM) 403 ONTC is switched (SW:ONTC) 51X MI X is diagnosed (DGN:MI=X,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed 52X NC X is diagnosed (DGN:NC=X,RAW,TLP) Same options as 51X 61X Network Clock Cross-Couple X hardware checks are inhibited (INH:HDWCHK,NCREF,XC=X) 71X Network Clock Cross-Couple X hardware checks are allowed (ALW:HDWCHK,NCFEF,XC=X) 90X Output the configuration status of ONTCCOM X (OP:CFGSTAT,ONTCCOM=X) 91X Output the configuration status of NC XC X (OP:CFGSTAT,NCREF,XC=X) CM1 Version 53X LI X is diagnosed (DGN:LI=X,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed The purpose of the 1211 display page is to show cross-couples between network clock oscillator (NCOSC) 0 & 1. It also shows the status of the NCOSCs, the oscillator cross-couples, and the network clock references. The 1211 display page has two separate versions. The first version (Figure .AW G238/) is the 24-channel version. The second version (Figure .AW G239/) is the 30-channel version. The 1211 page is only available in offices with the network clock model 2 hardware. The oscillator cross-couples (OSCXC) show the link status between the NCOSCs. If anything on the 1211 page is off-normal and backlighted, the SEE PAGE 1211 indicator on the 1210 page will be backlighted cyan, and the MI/NC (MI/LI/NC CM1) 0 or 1 indicator on Page 115 will be backlighted cyan. The NCOSC type is displayed in the NCOSC indicators. There are two oscillator types. They are medium stability (MED STAB) and high stability (HIGH STAB). The 24-channel version only allows three references per side. Only one reference per side can be in the active state at one time. The rest of the equipped references on that side will be in the standby state if they are not off-normal (that is, OOS, OOSF, etc.). The 30-channel version allows eight references per side. Again, only one reference per side can be active at one time. Also, there is a column between the reference columns titled LOCATION. The information in the LOCATION column is made up of three columns of information, colon (:) separated. These are the SMs which the reference comes from, the DLTU unit number in the SM, and the DFI number which provides the clock reference. This order is spelled out in the note which resides under the LOCATION box. The 24-channel version does not have the LOCATION column because the references in a 24-channel office are bridged off of a D-4 channel bank, whereas, in a 30-channel office, the references are bridged off of SMs. This LOCATION information is the only way the craft will know which SM, DLTU, and DFI to go to when there is a reference problem. Figure .AW G238/ shows the 24-channel version of the network clock page for network clock model 2 (NC2). This display shows the NCOSC 1 out of service. The NCOSC 1 being OOS causes OSCXC 0 to be out-of-service family of equipment (OOSF). The OSCXC 1 and all of the equipped references on side 1 are OOSF due to ONTC 1 being OOS. Figure .AW G239/ shows the 30-channel version on the network clock page. In this example, reference 3, side 1 is out of service because of a fault. The 1211 display page provides commands to remove, restore, and output the configuration status of the NCREFs, NCOSCs, and OSCXCs and to switch the NCREFs and the NCOSCs. All available display commands can be entered from the 1211 display page. 2 CMD RESULT 22X NCREF X (both sides) is removed (X=1 - 3 for 24-Chan.; X=1 - 8 for 30-Chan.) (RMV:NCREF,X) 23X NCOSC X is removed (RMV:NCOSC=X) 24X OSCXC X is removed (RMV:OSCXC=X) 32X NCFEF X (both sides) is restored (X=1 - 3 for 24-Chan.; X=1 - 8 for 30-Chan.) (RST:NCREF,X) 33X NCOSC X is restored (RST:NCOSC=X) 34X OSCXC X is restored (RST:OSCXC=X) 42X NCREF X (both sides) is switched (X=1 - 3 for 24-Chan.; X=1 - 8 for 30-Chan.) (SW:NCREF,X) 43X Side X NCOSC is switched (SW:NCOSC=X) 9XY Output the configuration status of Side X NCREF Y (1 - 3 for 24-Chan.; 1 - 8 for 30-Chan.) (OP:CFGSTAT,NCREF,Y=X) 93X Output the configuration status of Side X NCOSC (OP:CFGSTAT,NCOSC=X) 94X Output the configuration status of Side X OSCXC (OP:CFGSTAT,OSCXC=X) The purpose of the 1220 display page is to show status, to provide an index to the TMS LINK pages, and to provide maintenance commands for the TMSs. The 1220 page has two separate and distinct versions. The first version (Figure .AW G240/) is for offices with CM2 hardware. The second version (Figure .AW G241/) is for offices with CM1 hardware. The difference between the two versions is the note at the lower left of the display defining ONTCCOM (CM2 does not have a LI), the CM2 version shows a cross-couple between TMS 0 and TMS 1 that the CM1 version does not have, and the CM1 version has TMS 0 and 1 fan and fan fuse alarms and CM2 does not. Status shown for a TMS is actually the status of the ONTCCOM (MI/NC/TMS - CM2; MI/LI/NC/TMS - CM1), side 0 or 1. There is no separate status for the TMS. When an off-normal condition occurs in the ONTCs, the indicator on the 1220 page for the respective TMS backlights and CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. The TMS indicators on Display Page 115 will never be backlighted because there is no maintenance to be done from this page when something is off-normal. The index indicators on Display Page 1220 do not backlight when a TMS link goes off-normal because the craft is not directed to this page. The craft would be directed to the appropriate TMS LINK page from Page 115. Figure .AW G240/ shows the CM2 version of the TMS 0 and 1 SUMMARY page. This display example shows TMS 1 unavailable due to ONTCCOM 1 being unavailable, and TMS 0 is degraded forced due to ONTCCOM 0 being degraded forced. Figure .AW G241/ shows the CM1 version of the TMS 0 and 1 SUMMARY page. This display example shows the fan fuse alarm for TMS 0 is inhibited and TMS 0 is degraded. The maintenance commands shown are for the ONTCCOM, except for the diagnose commands which are provided for TMS. All available paging commands can be entered from the 1220 display page. 2 CMD RESULT 20X ONTCCOM X is removed (RMV:ONTCCOM=X) [,UCL] 30X ONTCCOM X is restored (RST:ONTCCOM=X) [,UCL] [,MAJOR/MINOR] 40X ONTCCOM X is forced active (SET:FRC,ONTCCOM=X) 402 ONTCCOM force is cleared (CLR:FRC,ONTCCOM) 403 ONTC is switched (SW:ONTC) 51X TMS X is diagnosed (DGN:TMS=X,RAW,TLP) [,UCL] [,RPT] test will be repeated 32,767 times [,RPT=a] a is the number of times the test is to be repeated (1-32,767) [,PH=b|b&&c] b is the diagnostic phase or b&&c is the range of phases to be performed The purpose of the 1221 display page is to show status and maintenance commands for the TMS links. The 1221 through 1228 and 1231 through 1238 group of displays are very similar. The 1221 through 1228 group is for TMS 0, and the 1231 through 1238 group is for TMS 1. Displays 1221 and 1231 show status for 62 links each; the rest of the displays show status for 64 links each. When an off-normal condition occurs for a TMSLINK, the indicator for the link backlights, the appropriate page number indicator on Page 115 backlights, and CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. If a DLI is out of service, the SM number will backlight and the TMSLNKs to that SM will be out-of-service family of equipment. Figure .AW G242/ is an example of the 1221 page which shows TMS link 18 out of service. This causes the CM indicator at the top of the screen to backlight. Note: The TMS links are part of the communication links (CLNKS), but the two types of links are not the same. The restore maintenance command for the TMS links are provided. The display command shown on the 1221 page example is of a related page. If both TMS links for an SM are out of service, action should be taken from the 1200 page for that SM, not from the TMS page. All available paging commands can be entered from the 1221 display page. Pages 1221 Through 1228 CMD RESULT 3XXX TMS Link XXX on TMS 0 is restored (RST:TMSLNK=0-XXX) Pages 1231 Through 1238 CMD RESULT 3XXX TMS Link XXX on TMS 1 is restored (RST:TMSLNK=1-XXX) The purpose of the 1240 and 1250 Pages is to show status and provide maintenance commands for the message switches (MSGS). The 1240 Page is for MSGS 0, and the 1250 Page is for MSGS 1. The 1240 and 1250 pages have two separate and distinct versions. The first version (Figure .AW G243/) is for offices with CM2 hardware. The second version (Figure .AW G244/) is for offices with CM1 hardware. One difference between the two versions is the reference to a connection to the MI/NC for the CM2 version versus to the MI/LI/NC for the CM1 version. The CM2 has no LI. Another difference is the CM1 version has MSGS fan and fan fuse alarms and the CM2 version does not. The last difference is the CM2 version has inhibit and allow hardware checks for the MSCUs and the CM1 version does not. The displays for MSGS 0 and MSGS 1 are very similar. When an off-normal condition occurs in the CMP, FPC, or PPC (Pages 1241/1251), the SEE PAGE indicator backlights on Pages 1240/1250, the 1241 or 1251 indicator on Page 115 backlights, and CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. When an off-normal condition occurs in an MMP (Pages 1242/1252 and 1243/1253), the SEE PAGE indicator backlights on 1240/1250, the 1242, 1252, 1243, or 1253 indicator on the 115 Page backlights, and CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight if applicable. Figure .AW G243/ is the CM2 version of the 1240/1250 page. The SEE PAGE 1242 indicator is backlighted because an MMP on 1242 is out of service. This causes the 1242 indicator under the MSGS 0 indicator to backlight on Page 115 - COMMUNICATION MODULE SUMMARY, which in turn causes the CM summary status indicator at the top of the screen to backlight. Figure .AW G244/ is the CM1 version of the 1240/1250 page. Commands are provided to remove, restore, diagnose, inhibit hardware checks, allow hardware checks, force, switch, and output the configuration status of the MSGS and its units. In addition, all available displays can be accessed from the 1240 or 1250 display pages. 3 MSGS 0 MSGS 1 CMD RESULT CMD RESULT 230 MSGS 0 is removed 231 MSGS 1 is removed (RMV:MSGS=0 [,UCL]) (RMV:MSGS=1 [,UCL]) 260 MSCU 0 is removed 261 MSCU 1 is removed (RMV:MSCU=0 [,UCL]) (RMV:MSCU=1 [,UCL]) 330 MSGS 0 is restored 331 MSGS 1 is restored (RST:MSGS=0 [,UCL]) (RST:MSGS=1 [,UCL]) 360 MSCU 0 is restored 361 MSCU 1 is restored (RST:MSCU=0) (RST:MSCU=1) 400 MSCU 0 is forced active 401 MSCU 1 is forced active (SET:FRC,MSCU=0) (SET:FRC,MSCU=1) 402 MSCU force is cleared 402 MSCU force is cleared (CLR:FRC,MSCU) (CLR:FRC,MSCU) 530 MSGS 0 is diagnosed 531 MSGS 1 is diagnosed (DGN:MSGS=0,RAW,TLP) (DGN:MSGS=1,RAW,TLP) [,UCL] [,UCL] [,RPT] test is run 32,767 [,RPT] test is run 32,767 times times [,RPT=a] where a is the [,RPT=a] where a is the number of times the test number of times the test is to be repeated (1-32,767) is to be repeated (1-32,767) [,PH=b|b&&c] where b is the [,PH=b|b&&c where b is the phase or b&&c is the range phase or b&&c is the range of phases to be performed of phases to be performed 560 MSCU 0 is diagnosed 561 MSCU 1 is diagnosed (DGN:MSCU=0,RAW,TLP) (DGN:MSCU=1,RAW,TLP) Same options as 530 plus Same options as 531 plus [,GROW] diagnose [,GROW] diagnose growth hardware growth hardware 660 Inhibit hardware checks 661 Inhibit hardware checks for MSCU 0 for MSCU 1 (INH:HDWCHK,MSCU=0) (INH:HDWCHK,MSCU=1) 760 Allow hardware checks 761 Allow hardware checks for MSCU 0 for MSCU 1 (ALW:HDWCHK,MSCU=0) (ALW:HDWCHK,MSCU=1) 930 Configuration status for 931 Configuration status for MSGS 0 is output MSGS 1 is output (OP:CFGSTAT,MSGS=0) (OP:CFGSTAT,MSGS=1) 960 Configuration status for 961 Configuration status for MSCU 0 is output MSCU 1 is output (OP:CFGSTAT,MSCU=0) (OP:CFGSTAT,MSCU=1) The purpose of the 1241 and 1251 pages is to show status and provide maintenance commands for CMPs, PPCs, and FPCs. The 1241 page is for MSGS 0 communities 0, 1, 8, and 9. The 1251 page is for MSGS 1 communities 0, 1, 8, and 9. The 1241 and 1251 pages have two separate and distinct versions. The first version (Figure .AW G245/) is for offices with CM2 hardware. The second version (Figure .AW G246/) is for offices with CM1 hardware. The difference between the two versions is the location of the CMP. The CMP is equipped in community 0 in the CM2 version and in community 1 in the CM1 version. The displays for MSGS 0 and MSGS 1 are very similar. When an off-normal condition occurs in the FPC or PPC, the indicator for the circuit backlights, the SEE PAGE 1241 (or 1251) on 1240 (or 1250) backlights, the 1241 or 1251 indicator on Page 115 backlights, and the CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. When an off-normal condition occurs in a CMP, the indicator for the circuit backlights, the SEE PAGE 1850 indicator backlights, the SEE PAGE 1241/1251 indicators backlight on Page 1240/1250, the 1241 or 1251 indicator on the 115 page backlights, and the CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight if applicable. Figure .AW G245/ is the CM2 version of the 1241/1251 page. Figure .AW G246/ is the CM1 version of the 1241/1251 page. Commands are provided to remove, restore, diagnose, inhibit hardware checks, allow hardware checks, switch, and output the configuration status of the CMPs, FPCs, or PPCs. In addition, all available displays can be accessed from the 1241 or 1251 display pages. 3 MSGS 0 MSGS 1 CMD RESULT CMD RESULT 2XX CMP XX is removed 2XX CMP XX is removed (RMV:CMP=0-XX) [,UCL] (RMV:CMP=1-XX) [,UCL] 240 FPC 0 is removed 241 FPC 1 is removed (RMV:FPC=0) (RMV:FPC=1) 250 PPC 0 is removed 251 PPC 1 is removed (RMV:PPC=0) (RMV:PPC=1) 3XX CMP XX is restored 3XX CMP XX is restored (RST:CMP=0-XX) [,UCL][,STBY] (RST:CMP=1-XX) [,UCL][,STBY] 340 FPC 0 is restored 341 FPC 1 is restored (RST:FPC=0) [,UCL] [,STBY] (RST:FPC=1) [,UCL] [,STBY] 350 PPC 0 is restored 351 PPC 1 is restored (RST:PPC=0) [,UCL] [,STBY] (RST:PPC=1) [,UCL] [,STBY] 4XX CMP XXs are switched 4XX CMP XXs are switched (SW:CMP=0-XX) [,UCL] (SW:CMP=1-XX) [,UCL] 440 FPCs are switched 441 FPCs are switched (SW:FPC) (SW:FPC) 450 PPCs are switched 451 PPCs are switched (SW:PPC) (SW:PPC) 5XX CMP XX is diagnosed 5XX CMP XX is diagnosed (DGN:CMP=0-XX,RAW,TLP) (DGN:CMP=1-XX,RAW,TLP) [,UCL] [,UCL] [,RPT] test is run 32,767 [,RPT] test is run 32,767 times times [,RPT=a] where a is the [,RPT=a] where a is the number of times the test number of times the test is to be repeated (1-32,767) is to be repeated (1-32,767) [,PH=b|b&&c] where b is the [,PH=b|b&&c] where b is the phase or b&&c is the range phase or b&&c is the range of phases to be performed of phases to be performed [,GROW] diagnose [,GROW] diagnose growth hardware growth hardware 540 FPC 0 is diagnosed 541 FPC 1 is diagnosed (DGN:FPC=0,RAW,TLP) (DGN:FPC=1,RAW,TLP) Same options as 5XX Same options as 5XX except GROW except GROW 550 PPC 0 is diagnosed 551 PPC 1 is diagnosed (DGN:PPC=0,RAW,TLP) (DGN:PPC=1,RAW,TLP) Same options as 5XX Same options as 5XX except GROW except GROW 6XX Inhibit hardware checks 6XX Inhibit hardware checks for CMP XX for CMP XX (INH:HDWCHK,CMP=0-XX) (INH:HDWCHK,CMP=1-XX) 640 Inhibit hardware checks 641 Inhibit hardware checks for FPC 0 for FPC 1 (INH:HDWCHK,FPC=0) (INH:HDWCHK,FPC=1) 650 Inhibit hardware checks 651 Inhibit hardware checks for PPC 0 for PPC 1 (INH:HDWCHK,PPC=0) (INH:HDWCHK,PPC=1) 7XX Allow hardware checks 7XX Allow hardware checks for CMP XX for CMP XX (ALW:HDWCHK,CMP=0-XX) (ALW:HDWCHK,CMP=1-XX) 740 Allow hardware checks 741 Allow hardware checks for FPC 0 for FPC 1 (ALW:HDWCHK,FPC=0) (ALW:HDWCHK,FPC=1) 750 Allow hardware checks 751 Allow hardware checks for PPC 0 for PPC 1 (ALW:HDWCHK,PPC=0) (ALW:HDWCHK,PPC=1) 9XX Configuration status for 9XX Configuration status for (OP:CFGSTAT,CMP=0-XX) (OP:CFGSTAT,CMP=1-XX) 940 Configuration status for 941 Configuration status for FPC 0 is output FPC 1 is output (OP:CFGSTAT,FPC=0) (OP:CFGSTAT,FPC=1) 950 Configuration status for 951 Configuration status for PPC 0 is output PPC 1 is output (OP:CFGSTAT,PPC=0) (OP:CFGSTAT,PPC=1) The purpose of the 1242, 1243, 1252, and 1253 pages is to show status and provide maintenance commands for the MSGS 0 and MSGS 1 MMPs. The 1242 page is for MSGS 0 communities 2 through 7. The 1243 page is for MSGS 0 communities 10 through 15. The 1252 page is for MSGS 1 communities 2 through 7. The 1253 page is for MSGS 1 communities 10 through 15. Although the 1242, 1243, 1252, and 1253 pages have two separate versions (CM1 and CM2), they are very similar in appearance and function. The 1242 example shown in Figure .AW G247/ is for offices with CM2 hardware. The second version of the 1242 page is shown in Figure .AW G248/ and is for offices with CM1 hardware. The difference between the two versions is the way the communities are equipped. The displays for COMMUNITIES 10 - 15 for MSGS 0 and MSGS 1 are very similar to the examples shown for COMMUNITIES 2 - 7. There are up to 48 MMPs across the 12 communities in each MSGS. The MMPs only appear on the displays if they are equipped. When an off-normal condition occurs, the indicator for the MMP backlights, the SEE PAGE 1242 (1243, 1252, or 1253) on 1240 (or 1250) backlights, the 1242 (1243, 1252, or 1253) indicator on Page 115 backlights, and CM backlights in the SUMMARY STATUS AREA. The associated alarm level (CRITICAL, MAJOR, or MINOR) will also backlight, if applicable. Figure .AW G247/ is an example of the CM2 version of Page 1242, MSGS 0 - COMMUNITIES 2 - 7. In this example, MMP 02 is shown out-of- service power. This causes the SEE PAGE 1242 indicator on 1240 to backlight and the 1242 indicator on Page 115 - COMMUNICATION MODULE SUMMARY to backlight which in turn causes the CM status summary indicator at the top of the screen to backlight. Figure .AW G248/ shows an example of the CM1 version of the MSGS 0 - COMMUNITIES 2 - 7 Page. The MMP 2 is unavailable power. The MMP 3 is active but has its hardware checks inhibited. Commands are provided to remove, restore, diagnose, inhibit hardware checks, allow hardware checks, and output the configuration status of the MMPs. In addition, all available displays can be accessed from the 1241, 1242, 1251, and 1252 pages. 3 MSGS 0 MSGS 1 CMD RESULT CMD RESULT 2XX MMP XX is removed 2XX MMP XX is removed (RMV:MMP=0-XX) (RMV:MMP=1-XX) 3XX MMP XX is restored 3XX MMP XX is restored (RST:MMP=0-XX) [,UCL] (RST:MMP=1-XX) [,UCL] 5XX MMP XX is diagnosed 5XX MMP XX is diagnosed (DGN:MMP=0-XX,RAW,TLP) (DGN:MMP=1-XX,RAW,TLP) [,UCL] [,UCL] [,RPT] test is run 32,767 [,RPT] test is run 32,767 times times [,RPT=a] where a is the [,RPT=a] where a is the number of times the test number of times the test is to be repeated (1-32,767) is to be repeated (1-32,767) [,PH=b|b&&c] where b is the [,PH=b|b&&c] where b is the phase or b&&c is the range phase or b&&c is the range of phases to be performed of phases to be performed [,GROW] diagnose [,GROW] diagnose growth hardware growth hardware 6XX Inhibit hardware checks 6XX Inhibit hardware checks for MMP XX for MMP XX (INH:HDWCHK,MMP=0-XX) (INH:HDWCHK,MMP=1-XX) 7XX Allow hardware checks 7XX Allow hardware checks for MMP XX for MMP XX (ALW:HDWCHK,MMP=0-XX) (ALW:HDWCHK,MMP=1-XX) 9XX Configuration status for 9XX Configuration status for MMP XX is output MMP XX is output (OP:CFGSTAT,MMP=0-XX) (OP:CFGSTAT,MMP=1-XX) The 1260 page shows a summary status of the CLNKs for all equipped SMs (up to 192). If a CLNK is off normal, the appropriate SM number is backlighted. If an SM is isolated, the SM number is backlighted and flashing (Figure .AW G249/). For further information, enter 1900,X to display the SM CLNK STATUS AND CONTROL page. Pages 1261-1264 are information only pages and should not be used for problem solving if an SM is backlighted. All available display commands can be entered from the 1260 display page. The 1261 through 1264 display pages summarize all logical communication links to the SMs. The 1261 through 1264 displays for LOGICAL LINK MAPs 1 through 4 are very similar. Page 1261 summarizes all logical communication links to SMs 1 through 48. Page 1262 summarizes all logical communication links to SMs 49 through 96. Page 1263 summarizes all logical communication links to SMs 97 through 144. Page 1264 summarizes all logical communication links to SMs 145 through 192. These pages (1261 through 1264) are information-only type pages. The links shown on the 1261 through 1264 pages are the logical communication links which 1900,X - SM X CLNKS displays the status of on a per-SM basis. The ONTC column is the ONTC the link is routed through, the MSGS column is the MSGS the link is routed through, and the MMP column shows the MMP type the link is routed through. A 0 in the MMP column means the MMP used works through the even time slots and a 1 in the MMP column means the MMP works through the odd time slots. In the Figure .AW G250/ Display Page 1261 example, no paths are shown for SM 6 which is isolated. Further information and maintenance commands for the links are found on the SM 6 CLNKS display. All available displays can be accessed from the 1261 through 1264 pages. The 1271, 1272, 1273, and 1274 page displays provide summary status for routine exercises for the CM and the SMs as follow: o 1271 - SM 1 - 48 and CM REX SUMMARY o 1272 - SM 49 - 96 REX SUMMARY o 1273 - SM 97 - 144 REX SUMMARY o 1274 - SM 145 - 192 REX SUMMARY. The four REX SUMMARY pages are very similar. The first page, 1271, provides REX summary status for the CM and for the first 48 SMs. The second page, 1272, provides REX summary status for the next group of 48 SMs, SM 49 through 96. The third page, 1273, provides REX summary status for SMs 97 through 144. The fourth page, 1274, provides REX summary status for SMs 145 through 192. If an SM is equipped, the number for the SM appears on the appropriate REX SUMMARY page. If REX is not in progress or inhibited for one or more units or the entire SM, nothing more than the number is displayed. If REX is running on an SM, the status of IP is shown immediately to the right of the SM number; and further to the right, the type(s) of REX test(s) is displayed. On color terminals, the indicator is black on green. If REX is inhibited for an SM, the status of INH appears immediately to the right of the SM number and the indicator for the SM is backlighted, black on white for black and white terminals, and blue on yellow for color terminals. The status of inhibit can mean that one or more units in the SM have been inhibited from running REX or that the whole SM is inhibited from running REX. Also, on Page 1010,X, the phrase SEE 1800 will appear (backlighted) in the RELATED PAGES box. On Page 114, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and the phrase INHIBITS will be written, unless a more critical condition exists. The three REX test types for an SM are as follows: o DGN: Full diagnostics. This results in a conditional restore request including the trouble location procedure (TLP) option. o ELS: Electric loop segregation. This tests customer lines to determine a suitable network balance necessary to reduce the amount of potential echoing in the transmission path. o FAB: Fabric exercise. This tests the operation of the gated diode crosspoints (GDX) in the line unit (LU) concentrator grid or grid board. For detailed status of SM REX schedules and any in progress units, 1280,X should be entered, where X is the SM number desired. For the CM, the appropriate REX types are as follows: o DGN: This is the same as for the SM. o SWITCH: Partial Diagnostic. This results in a soft switch of the PPC, the FPC, the CMP, and the ONTC. No diagnostics are executed. For detailed status of the CM REX schedule and any in progress units, enter 1290. The 1271 display page is the first of four REX Summary pages. In Figure .AW G251/, the summary for the CM shows that REX is in progress on some unit in the CM. The SM 2 has ELS and FAB in progress; SM 4 has DGN and FAB inhibited; SM 7 has DGN in progress; SM 11 has DGN, ELS, and FAB inhibited; SM 20 has DGN inhibited, SM 24 has DGN and ELS in progress; and SM 48 has nothing inhibited or no test in progress. All available displays can be accessed from the 1271 through 1274 display pages. The purpose of the 1280 page is to provide the status of REX in an SM on a per unit basis and to display the REX schedule for the SM. Read the note under the MCC display on the previous page. The 1280 page shows all of the units equipped in the SM, for which it is being displayed, that REX will exercise. Only one unit at a time may have REX in progress while any number of units at a time may have REX inhibited on those units. If a unit shows the state of in progress (IP) or inhibited (INH), it reflects the state of DGN. Both ELS and FAB do not specifically show up because they apply to the SM as a whole. The REX schedule displays the start time in hours and minutes and the duration of DGN, ELS, and FAB in hours. It shows the setting of REX Verbose; Y if verbose is turned on, N if verbose is turned off. For each day of the week, the schedule displays whether DGN, ELS, and FAB are scheduled to run for that day; F means full tests are scheduled and N means REX is not scheduled for that day on that SM. If REX is inhibited for the entire SM due to the input message INH:REX,SM=SM#, a note will appear at the upper right area of the page that says REX INHIBITED - SEE 1800 and it will be backlighted. Note: If the module controller is an SMP20, the bootstrapper status is not displayed. The SMP20 processor is also referred to as the module controller/time slot interchange model 2 (MCTU2). For non-SMP20 SMs, the bootstrapper status will be displayed on the 1280 page display. Figure .AW G252/ is an example of the SM REX STATUS page. In this display for SM 7, DGN starts at 12:30 a.m. (HRS=00, MINS=30) and runs for 2 hours. The ELS starts at 2:30 a.m. (HRS=02, MINS=30) and runs for 2 hours. FAB starts at 4:30 a.m. (HRS=04, MINS=30) and runs for 2 hours. REX on line unit 0 is in progress and is inhibited on line unit 1. Commands are provided for executing DGN, ELS, or FAB REX and for outputting the status of REX for the SM for which the page is displayed. All available display commands can be entered from the 1280,X page. CMD RESULT 500 Execute (start) REX DGN (EXC:REX,SM=SM#,DGN) 501 Execute (start) REX ELS (EXC:REX,SM=SM#,ELS) 502 Execute (start) REX FAB (EXC:REX,SM=SM#,FAB) 900 Output status of REX for the SM (OP:REX,SM=SM#) The purpose of the 1290 display page is to provide the status of REX for the CM and to display the REX schedule for the CM. The 1290 page shows the REX status for the ONTCs and the MSGSs. Only one unit will have REX in progress at a time, while any number of them may have REX inhibited. If a unit shows the state of in progress (IP), it reflects the state of DGN. The 5ESS switch will cause the FPC, PPC, CMP, and ONTC to be soft switched but will not run any tests and will not cause any status to be displayed on the page. The REX schedule displays the start time in hours and minutes and the duration in hours. It shows the setting of REX Verbose, Y if verbose is turned on, N if verbose is turned off. For each day of the week, the schedule displays whether DGN is scheduled to run for that day; F means full diagnostic tests are scheduled, N means not scheduled, and P means partial test are scheduled (switch). If REX is inhibited for the entire CM due to the input message INH:REX,CM, a note will appear at the upper right area of the page that says REX INHIBITED - SEE 110 and it will be backlighted. Figure .AW G253/ shows REX in progress on MSGS 1. The schedule indicates that DGN is scheduled at half past midnight (HRS=00, MINS=30) and runs for 3 hours on Mondays, Wednesdays, and Fridays. The REX verbose is turned on. On Saturday, a partial switch will be done. Commands are provided for executing full DGN exercises or partial DGN exercises (SWITCH) and for outputting the status of REX for the CM. All available displays can be accessed from the 1290 display page. CMD RESULT 500 Execute (start) full REX DGN (EXC:REX,CM,DGN) 501 Execute (start) partial REX DGN (EXC:REX,CM,SWITCH) 900 Output status of REX for the CM (OP:REX,CM) The purpose of the 131Y,X through 136Y,X pages is to show status for SLC 96 Carrier RTs, if equipped. The displays for RT1 through RT6 are very similar. There are several possible configurations for the RT pages. A typical configuration is shown in the 131Y,X - SM X - DCLU Y - RT1 example. If an off-normal condition occurs in any of the SDFIs, the corresponding SDFI indicator will be backlighted and have text written in. To the right of SDFI in the SDFI indicators is the SDFI number that indicator represents. Its associated facility is below the SDFI indicator box and will be backlighted if off- normal. Each facility (A, B, C, or D) has an associated SHELF indicator. If there is an off-normal condition in a shelf, the SHELF indicator will be backlighted. If a SHELF or SHELF GROUP is in an off-normal state, the RT indicator on the 115Y page will be backlighted, as will the DCLU indicator on the 1010 page, and the SM indicator on the 114 page. On the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and CKT OOS will be written. In the SUMMARY STATUS AREA, the SM indicator and the alarm level will backlight. Facilities A and C each have a SHELF GROUP indicator. They can be configured with either their SHELF or SHELF GROUP, unless facility B or D are equipped. If B is equipped, facility A must be configured with a shelf. If facility D is equipped, facility C must be configured with a shelf. If a facility is off-normal (and all SDFI and SHELF indicators are normal), then the RT indicator on the 115Y page will be backlighted, as will the DCLU indicator on the 1010 page. If the FACOFFN option is turned off (CLR:S96,FACOFFN), the SM indicator on the 114 page will remain normal, as will the SM indicator on the 141, 142, 143, or 144 page. When facility P is replacing a facility, then the RT indicator on the 115Y page will be backlighted, as will the DCLU indicator on the 1010 page. If the FACOFFN option is turned off (CLR:S96,FACOFFN), the SM indicator on the 114 page will remain normal, as will the SM indicator on the 141, 142, 143, or 144 page. If the FACOFFN option is turned on (SET:S96,FACOFFN) and either an FAC is off-normal or facility P is replacing a facility, then the SM indicator on the 114 page will be backlighted, as will the SM indicator on the 141, 142, 143, or 144 page with an appropriate descriptive phrase (CKT OOS or SLC PLS). In the SUMMARY STATUS AREA, the SM indicator and the alarm level will backlight. Facility P is a protection facility. If one of the equipped facilities is OOS but the shelf or shelf group is ACT, facility P will replace the OOS facility. It may also replace a facility that is ACT (if there is a manual request or a problem at the RT). Facility P is optional. To the left of shelf A is the PWR/MISC alarm indicator. If there is a Power/Miscellaneous alarm at the RT, the indicator will be backlighted and either MJ (major) or MN (minor) will appear in the indicator. The RT indicator on the 115Y page will be backlighted, as will the DCLU indicator on the 1010 page, and the SM indicator on the 114 page. On the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and BLDG/PWR will be written. In the SUMMARY STATUS AREA, the SM indicator and the alarm level will backlight. The subscriber loop carrier identification number (SID) is displayed underneath the SHELF A indicator. Figure .AW G254/ shows RT1 has SDFI 4 out of service (OOS). It is associated with facility B which is out-of-service family (OOSF) of equipment. The SDFI 6 is OOS and its associated facility (C) and shelf group (CD) are OOSF. The protection facility (P) has taken over for facility B. There are no commands for the 131Y,X - 136Y,X pages, but all available displays can be accessed from this page. The purpose of the 1400,X page is to display building/power alarm status and assignment and the alarm retire mode. It also provides inhibit/allow controls for building alarms and sets the alarm retire mode in the remote switching module (RSM). In addition, the 1400,X page displays status and provides controls in the optically remoted module (ORM). When 1400,X is poked, the page display reflects either RSM data or ORM data. If ``X'' is the number of an RSM, then RSM data is shown. Conversely, if ``X'' is the number of an ORM, then ORM data is shown. The 1400,X page has three separate and distinct versions, depending on the hardware equipage in the RSM/ORM. Version one (Figure .AW G255/) is displayed if 1400 is requested for an RSM/ORM equipped with both scan and distribute boards for the BLDG/PWR alarms and the alarm and status circuit (ASC). Version two (Figure .AW G256/) is displayed if 1400 is requested for an RSM/ORM equipped with a remote alarm unit and a metallic service unit or modular metallic service unit. Version two is also displayed if 1400 is requested for an RSM/ORM equipped with scan boards for the BLDG/PWR Alarms but not the ASC. Version three (Figure .AW G257/) is displayed if 1400 is requested for an RSM/ORM equipped with an ASC but not the scan boards for the BLDG/PWR Alarms. If none of these hardware requirements are met, the page is not displayed if requested, and no BLDG/PWR ALARM indicators will be displayed on the 1010 page. If no RSM/ORM at the site meets these hardware requirements, no BLDG/PWR Alarm indicator will appear on the 1600 page. Building alarms 02-31 and their alarm levels are office assignable. Doors, windows, humidity, etc., are typical types of applications. The alarm level and text in these indicators are initially filled in using recent change and verify. Once these indicators are filled in, they are protected from loss if the system is booted. A normal alarm indicator is displayed in normal video (white on black). Except for the FIRE indicator, when an alarm condition is present and it is not inhibited, the respective display indicator will backlight. The FIRE indicator flashes in addition to becoming backlighted. On Display Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted and flashing, and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted and flashing, and the phrase CRIT ALM will be written. In the SUMMARY STATUS AREA, the SM critical indicator will start flashing, and the alarm level indicator CRITICAL will be backlighted. Also, an audible alarm will be sounded. For alarm indicators other than FIRE, on Page 114, the indicator for that SM will be backlighted; and on the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted, and a descriptive phrase of the condition will be written unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM indicator and the alarm level (CRITICAL, MAJOR, or MINOR), if applicable, will be backlighted. When an alarm is inhibited, the respective indicator will have ``INH'' written in and will be backlighted; SM in the SUMMARY STATUS AREA will also backlight. Building alarms 02-31 are the only alarms on the 1400 page that can be inhibited by the craft. The alarm retire mode indicator, if present, reflects the mode of the alarm retire function of the alarm lights and audibles at the RSM/ORM sites. If set to automatic, the audible alarms at the RSM site and alarm lights on the alarm and status panel retire automatically after a certain time period specified by an office definable parameter in the ODD for that RSM/ORM. If set to manual, the craft is required to manually retire the alarms by pressing the ALM RETIRE button on the RSM/ORM alarm and status panel. Figure .AW G255/ is an example of version one where an ORM is equipped with both scan and distribute boards for the BLDG/PWR alarms and the alarm and status circuit (ASC). In this example, indicator 05 shows a major alarm caused by a failure in the air conditioning system. Indicator COM PWR shows that there is a commercial power failure. Figure .AW G256/ shows an example of version two in which an RSM is equipped only with the Building/Power Alarms (or the RSM is an earlier vintage equipped with a Remote Alarm Unit). In this example, building alarm 9 is inhibited. Figure .AW G257/ is an example of version three where an RSM is equipped with the alarm and status panel but not equipped with scan boards for building/power alarms. In this example, the alarm retire mode is set to automatic. Commands are provided to inhibit/allow building alarms 02-31 and to set the ALARM RETIRE mode to automatic or manual. Also, all available pages can be accessed from the 1400 display page. CMD RESULT 6XX RSM/ORM Building Alarm XX is inhibited (INH:ALM,RBPSC=XX,SM=SM#) 7XX RSM/ORM Building Alarm XX is allowed (ALW:ALM,RBPSC=XX,SM=SM#) 800 Sets the Alarm Retire Mode to automatic (SET:ALMMDE=AUTO, RBPSC,SM=SM#) 801 Sets the Alarm Retire Mode to manual (SET:ALMMDE=MAN,RBPSC,SM=SM#) The 1420 page display provides the status of the remote integrated services line unit (RISLU) site alarms. A maximum of eight RISLUs can be equipped per RISLU site. One RISLU per site is equipped with a remote alarm section (RAS). Each RAS has 32 miscellaneous scan points, where up to 30 of these scan points are office definable (02-31). The first two scan point definitions are fixed (00 = Fire Alarm, and 01 = Fire Alarm Trouble). Also, these scan points cannot be inhibited. In the RETIRE MODE indicator field, the term MANUAL appears when the poke command 801 is entered; and the term AUTOMATIC appears when the poke command 800 is entered. Figure .AW G258/ shows an example of the 1420 page display. The following commands inhibit, allow, and retire RISLU building/power alarms: CMD RESULT 6XX Inhibit scan point XX (INH:ALM,RIBMSC=XX,SITE=a) 7XX Allow scan point XX (ALW:ALM,RIBMSC=XX,SITE=a) 800 Scan point alarms retire automatically (SET:ALMMDE=AUTO,RAS,SITE=a) 801 Scan point alarms require manual action to be retired (SET:ALMMDE=MAN,RAS,SITE=a) The 145Y page display [where ``Y'' is equal to the digital line trunk unit (DLTU) number (0 or 1)] provides the status of remote and host digital facility interfaces (DFI) and the status of the remote clocks. One RISLU digital line trunk unit (DLTU) can host two RISLUs. The ``*'' (located to the left of the first and third lines of data in the box on the right half of this page face) indicates these host DFIs are controlling the active RRCLK on the RISLU. Switching module 115 is hosting two RISLUs; therefore, two control facilities are indicated. A maximum of 16 host/remote RISLU DFI pairs can be equipped per RISLU DLTU. The 1451 display page can be accessed from the 1000 SM PAGE INDEX display page. Also, the 170Y,X ISLU Y display page can be accessed from this display page. Figure .AW G259/ shows an example of the 1451 display page. The following commands can be used to remove, restore, and diagnose the RISLU clock and the host DFI. All available displays can be accessed from this page. CMD RESULT 2YX Remove RRCLK Y RISLU X (RMV:RRCLK=a-x-y, SCREEN=b) 22XX Remove DFIH XX (RMV:OF1H=a-b-XX) 3YX Restore RRCLK Y RISLU X (RST=RRCLK=a-x-y, SCREEN=b) 32XX Restore DFIH XX (RST=DF1H=a-b-xx) 5YX Diagnose RRCLK Y RISLU X (DGN=RRCXLK=a-x-y,RAW,TLP) 52XX Diagnose DFIH XX (DGN=DF1H=a-b-y,RAW,TLP) 40X Switch RRCLK RISLU X (SW=RRCLK=a-x, SCREEN=b) 170Y Display ISLU NETWORK Y Note: The term basic rate interface (BRI) means the same thing as digital subscriber line (DSL). This document uses DSL, because the 1460 page display does not identify BRI. The 1460 page display provides summary status of the Operator Services Position System (OSPS) data links on a per-SM basis. The 1460 page display is not normally accessed when DSLs are IN SERVICE. Usually the 1460 page is accessed because of the following: o DSL MAJOR or DSL MINOR alarm is indicated in the SM X STATUS indicator box on the 1010-SM X LSM STATUS page display. o SEE 1460 is present in the RELATED PAGES box on the 1010-SM X LSM STATUS page. This page display provides the following: o Which data link types are equipped in an SM. Note: If no ports are equipped for a specific data link in the SM, then no data link block appears on the 1460 page display. o Which data link types have ports OOS and the relative seriousness of the fault. Each data link type has an associated indicator block. If a block is backlighted red, a minor alarm is indicated; also, the term DSL_MINOR is displayed in the SM XXX STATUS indicator block. If a block is flashing from red to white, a major alarm is indicated; also, the term DSL_MAJOR is displayed in the SM XXX STATUS indicator block. o Which page display gives more details (for example, equipment numbers or states) concerning each data link type equipped in an SM. On the 1460 page display (Figure .AW G260/), one of the data links represented is DAS/C with the associated page to see for more details (for example, SEE 147000). Where the first two zeros = the data link type (service class) and the last zero indicates the screen number of the specific service class. There are two types of data links (service classes) - simplex and duplex. The following are simplex data links: Note: The XDB data link is the only link that can be equipped with more than 16 ports. o HOBICV o HOBIS o HOBICR o AQ o XDB. The following are duplex data links: o DAS/C o RAS o RTRS o MISLNK. The external information system (EIS) data link introduced in 5E6 is an N+K data link group, where N+K is defined in the alarms section. Major and Minor Alarms For simplex data links, if more than 50 percent of the ports associated to a specific data link (per-SM) are OOS (out of service), a major alarm occurs. For simplex data links, if one but no more than 50 percent of the ports associated to the data link are OOS, a minor alarm occurs. Note: If exactly 50 percent of the ports associated to a specific data link are OOS, a minor alarm occurs. For the duplex DAS/C and RTRS data links, the DAS and RTRS data links can be equipped with a maximum of two ports each. If only one port is assigned to DAS/C or RTRS and the port is OOS, a major alarm occurs. If two ports are assigned to DAS/C or RTRS and one port is OOS, a minor alarm occurs; and if both ports are OOS, a major alarm occurs. For the duplex RAS data link, a maximum of eight RISLUs can be equipped with RAS (that is, on a per-SM basis). Each RISLU site can be assigned up to a maximum of two RAS data links, therefore, providing a maximum of 16 data links per SM. A minor alarm occurs when at least one RAS data link is OOS, but all of the RISLU sites have at least one RAS link in service. A major alarm occurs when at least one site has all RAS links OOS. Some RISLU sites may only be equipped with one RAS link; when or if this link is OOS, a major alarm occurs. EIS Alarm Strategy The following terminology is used to define EIS data link alarm strategy for an SM: The set of EIS data links equipped on a specific SM and connected to a specific EIS is referred to as an ``EIS Call Processing Data link (CPDL) group.'' Each EIS CPDL group consists of (N+K) data links, where N and K are specified independently for each EIS CPDL group: 1. N, indicating the minimum number of CPDLs that are needed to support the message traffic during the busy hour for the EIS CPDL group. 2. K, the number of CPDLs providing surplus traffic capacity for the EIS CPDL group. The EIS data link summary status for an SM is defined as follows: o DSL_NORMAL: All EIS data links on the SM are in-service. o DSL_MINOR: At least one EIS data link equipped on the SM is out of service, but each EIS CPDL group has at least N EIS data links in-service. o DSL_MAJOR: At least one EIS CPDL group has fewer than N EIS data links in service. Figure .AW G260/ shows an example of the 1460 page display. Any available paging commands can be entered from this display. The 147YYZ page display provides the global port names, the DSL names, and the DSL status for all of the port assigned the data link type (for example, XDB). If you have not read the information concerning the 1460 page display, then do so, because it has information that is associated to the 147YYZ page display. The GLOBAL PORT NAME field contains the channel type (B1 or D) followed by the LCEN. The LCEN (for example, 17-4-07-02) represents the following: 17 = SM, 4 = ISLU or RISLU, 07 = line group controller, and 02 = line card. The DSL NAME field contains the data link type (for example, XDB), external name identifiers, and associated link numbers. The DSL STATUS field contains the status of the DSLs. The SM XXX STAT indicator block provides the relative seriousness of the fault (major or minor alarm). The SCREEN Z SUMMARY indicator block identifies the number of screens available to be displayed. More importantly, if any of the screen numbers are backlighted red, this means that one or more of the ports on that specific screen are OOS. The user can identify which screen of the data link is being reviewed by looking at the left-hand side of the 147YYZ page display under the SCREEN Z SUMMARY indicator. Figure .AW G261/ illustrates the XDB data link version of the 147YYZ page display [where ``YY'' equals the data link type (service class) and ``Z'' equals the screen of the specific data link type]. The XDB data link type is the only type that can be equipped with more than 16 ports. The 14707Z poke command gives the user the ability to choose the screen to be displayed (where ``Z'' = the screen number). Also, any poke command can be entered from this display. The 1480,X page display provides the status of application processor (AP) digital subscriber lines (DSL) and associated session status. The AP LINK indicator field illustrates the AP index number and AP link number, for example, AP 04-01 (where 04 = AP index number and 01 = AP link number). The DSL LCEN indicator field illustrates the line unit (LU), line group controller (LGC), and line card (LC) numbers. An example is, 001-0-12-24 [where 001 = Switch Module number, 0 = Line Unit number, 12 = Line Group number, and 24 = Line Card number]. If all of the data links associated to an AP are out of service (OOS), the term DSL MAJOR appears in the SM XXX STATUS indicator block. This means a major alarm has occurred, provided that the alarm request for the AP has been set to Y (YES) via RC/V view 24.7. If one or more but not all data links for an AP are OOS, the term DSL MINOR appears in the SM XXX STATUS indicator block. This means a minor alarm has occurred, provided that the alarm request for the AP has been set to Y (YES) via RC/V view 24.7. In the 5E7 software release, another alarm level, CRITICAL, is added, provided that the SM is attached to an E911 AP. The AP data link alarm is elevated one level higher for the E911 AP links. If all links for a given AP are OOS and the AP is an E911 AP, the term E911_CRIT will appear in the SM XXX STATUS box. If at least one but not all links for a given AP are OOS and the AP is E911 AP, the term DSL MAJOR will appear in the SM XXX STATUS box. The SESSION indicator field illustrates the chain of events that occur when the AP data links are being assigned. When this field contains DISC, the DSL is OOS, or the AP data link is not assigned. When INIT appears in the SESSION field, level 3 implementation has been completed; and when the implementation of the data link is complete (that is, level 4), the SESSION field contains the term CONN. Also, the SESSION field can contain the term MAINT. This occurs when the AP has requested a maintenance exercise. Figure .AW G262/ shows an example of the 1480,X page display. All available page display commands can be entered from the 1480 page. CMD RESULT 200,X,Y APX DATA LINK Y is removed (RMV:DATALINK,AP=a-b) 300,X,Y APX DATALINK Y is restored (RST:DATALINK,AP=a-b) The purpose of the 1600,SZ page is to show the status of all of the RSMs at a site and their associated HSMs and interconnections. The 1600,SZ page shows the RSMs that are located at a particular site. A site may have from one to four RSMs located at it. Each RSM may have a separate HSM hosting it or one HSM may host more than one of the RSMs up to hosting all four RSMs. The SITE STATUS page can be requested by craft using the SM number of any RSM at the site or by using the corresponding site number in 1600,SZ (where ``S'' is actually typed as part of the command and ``Z'' = site number). The integrity of craft access to the page is enhanced since the page is available if craft can communicate to any of the RSMs at the site. The accuracy of the information shown on the page is not affected by failures in the T1 communication links unless, in addition, the RSMs become separated from each other. If all T1 communication links to the site fail, the page is not available. This display graphically shows the intercommunication link (ICL) groups between the RSMs; and on the right side of the page, the status of the ICL groups is displayed. The title of this page contains the number assigned to a site and the actual name of the site. An ICL is a single link between a pair of RSMs. The status displayed on the right, therefore, is a summary of each link group. The possible states a link group may have are as follows: o ACT (Active): All ICLs of the link group are in service. o DGR (Degraded): At least one, but not all ICLs of the link group is out of service. o MSEP (Manually Separated): All ICLs of the link group are out of service due to a manual craft request. o SEP (Separated): All ICLs of the link group are out of service for any reason other than a craft request. Next to each RSM indicator is the timing mode indicator for that RSM. This indicator displays the means by which the RSM derives its timing. The RSMs will take their timing from whichever mode is the most stable. The possible timing modes are as follows: o T1: The RSM is getting its timing over the T1 umbilical from the HSM. o RCLK: This is the normal mode for the RSM which has the RCLK equipped as long as the RCLK is the most stable of the modes. o ICL: This means that the RSM is getting its timing from another RSM over the ICL. o FI: The RSM is isolated and separated (no T1 and no ICLs) and is generating its timing internally. If a site is equipped with building and power alarms, an indicator will be displayed on the left side of the page showing the BLDG/PWR ALARM status and to which RSM it is connected (Figure .AW G264/). If a site is equipped with a remote clock unit, an indicator will be displayed on the left side of the page showing the RCLK mode and to which RSM it is connected (Figure .AW G264/). Figure .AW G263/ is an example of the 1600,SZ page which shows status of SITE 2. SITE 2 has three RSMs which are hosted by two different HSMs. The Inter-Communication Links are all active. The RSM 192 is getting its timing from HSM 12 over the T1 umbilical, and RSM 5 and 11 are getting their timing from RSM 192. Figure .AW G264/ is an example of the SITE STATUS page which shows a site with both the remote clock and building/power alarms equipped. In this example, there is a building/power alarm active. Also, RSM 48 has an RCL circuit out of service, which caused the three ICL groups to it to be degraded. The RSM 48 is getting its timing from the remote clock which is in normal mode and the other three RSMs are ICL based, getting their timing from RSM 48 over the ICLs. All available displays can be accessed from the 1600 display page. The 1610 page display provides a list of remote switching modules and associated site numbers. The 1610 is an information only page which shows all remote sites associated with an office. The status of remote switching modules can be verified by typing 1600,SZ (the ``S'' is actually typed as part of the command and ``Z'' = site number). Figure .AW G265/ is an example of the 1610 page. All available MCC page display commands can be entered from the 1610 page display. The 1615 page display provides a list of the ORMs and their associated site numbers. The status of the ORMs can be verified by typing 1010,SM (where SM = SM number). Figure .AW G266/ is an example of the 1615 page. In the message 002 011 SITE 2 - ORM11 shown, 002: is the ORM site number, 011: is the SM number, and SITE 2 - ORM11: is the site name. All available MCC page display commands can be entered from the 1615 page display. The 1620 page display provides the connections between the SM and RISLU site(s) and the status of each RISLU site(s). The BLDG/PWR ALARMS box of this page identifies the building/power alarm summary status and indicates which RISLU is hosting these alarms. The 1620 page display can be accessed from either the 1000 SM PAGE INDEX or 1630 RISLU SITE INDEX pages. Up to eight SMs and RISLUs can be displayed from the 1620 page. Figure .AW G267/ shows an example of the 1620 page display. The status of the building/power alarms for a particular RISLU site can be displayed by entering 1420,SZ, where ``S'' equals the actual letter ``S'' and ``Z'' equals the RISLU site number. Also, the associated ISLU network pages can be accessed by entering 170Y,X, result -- SM X ISLU Y NETWORK. The 1630 page display provides the list of RISLU sites on the SM. The 1630 page lists the number and name of each RISLU site. The status of each RISLU site can be displayed from the 1630 page display, by entering 1620,SZ (where Z=RISLU site number) (the ``S'' is actually typed as part of the command). The 1630 page display can be accessed from the 1000 SM PAGE INDEX display page. Figure .AW G268/ shows an example of the 1630 page. Any available paging commands can be entered from this display. The 170Y,X page display provides the ISLUCCs and ISLUCDs status and a summary status for the LG. The ISLU network display page simultaneously shows the state of both ISLUCCs and both ISLUCDs and a status summary of the LGs. The status of the ISLUCCs is noted on the MCC as duplex SM peripheral controllers. When the ISLUCDs are running in a load shared configuration, the status indication for the CDs on the MCC display is ACTIVE-MAJOR/ACTIVE-MINOR. If the CDs are not to run in a load shared configuration, the status indication for the CDs will be ACTIVE/STANDBY. When load sharing is run, a request to conditionally remove a CD is displayed as ``CAMP'' until all calls routed through the CD are terminated. Then the CD is marked ``OOS.'' If the remove should time out or be stopped before all calls are terminated, the CD is marked ``ACT'' with no call loss. When any LC or LGC is removed from service, the LG status summary displays the trouble by backlighting the unit number of the LG in which the OOS unit resides. The 170Y,X page display can be accessed from the 1000-SM page index and the 1620,SZ RISLU SITE STATUS pages. Figure .AW G269/ shows an example of the 170Y,X page display. Commands are provided to remove, restore, diagnose, switch the clock, and display ISLU LG page display concerning the ISLU network. CMD RESULT 20X Removes ISLUCC X 21X Removes ISLUCD X 30X Restores ISLUCC X 31X Restores ISLUCD X 50X Diagnoses ISLUCC X 51X Diagnoses ISLUCD X 40X Switches ISLUCC X 41X Switches ISLUCD X 170YZZ Displays ISLU Y LG ZZ The 170Y,X page display provides information concerning the ISLU network and status of DFIs on the DLTU. The 170Y,X page display can be accessed from either the 1620- RISLU SITE X STATUS or the 1451-SM X-RISLU DLTU page. The 1701 page display indicates where the ISLU is located. In this case, the figure illustrates that the ISLU is remoted to SITE 500. This means that the ISLU is really an RISLU because the ISLU is remote. The SITE number is indicated just below the SM STATUS box. Note: This site is the site of the SM hosting the RISLU, not the RISLU site. A fan and fuse alarms indicator box gives the status of the alarms for the RISLU network. A duplex configuration exists for ISLUCC and ISLUCD. That is, when ISLUCC 0 is active then ISLUCC 1 is on standby (backup), and the same is true for ISLUCD 0 and 1. Each LG (maximum of 16) can be connected to an ISLUCD circuit that is controlled by the ISLUCC. Figure .AW G270/ shows an example of the 170Y,X page display. Commands are provided to remove, restore, and diagnose the ISLU CC and CD circuits. Any available paging commands can be entered from this page. CMD RESULT 20X ISLUCC X is removed 21X ISLUCD X is removed 30X ISLUCC X is restored 31X ISLUCD X is restored 40X ISLUCC X is switched 41X ISLUCD X is switched 50X ISLUCC X is diagnosed 51X ISLUCD X is diagnosed 145Y RISLU DLTU Y is displayed 170YXX ISLU Y LG XX can be displayed 171Y ISLU Y SG XX (0 & 1) can be displayed The 170YZZ page display provides the LGC status and each LC status and type for the LG of the ISLU network. The ISLU LG display pages (one per LG) display the LGC status and individual LC status and type. The data of each of the ISLU LG pages supplies the LG status entry in the summary of the ISLU Network display. The possible states of the LGC and LCs will be ACT, CAMP, OOS, OOSFE, GROW, and UNEQ. A new state customer deny (CDNY) applies for the LGC. Two new states, spare (SPR) and designated spare (DSPR) apply for the LC. When the LGC is unequipped, growing, or OOS, the LCs can be of the same state or OOSFE. A request to conditionally remove an LGC is displayed as CAMP until all LCs can terminate and be marked OOS. Once all the LCs are removed and marked OOSFE, the LGC is removed as well and marked OOS. If the remove should time out or be stopped before all the LCs and LGC are removed, the LGC is marked CDNY. A request to conditionally remove an LC is displayed as CAMP until the LC call is terminated, upon which, the LC is marked OOS. If the remove should time out or be stopped before the call is terminated, the LC is marked as before the remove request, active. If any portion of the LCs or the LGC is OOS, the trouble is reflected on the LG status summary of the ISLU Network display by backlighting the unit number of the LG. The appropriate peripheral status block of the SM on the SM STATUS page is marked with the ISLU. When any portion of the ISLU is OOS, the block is backlighted. If the status reported on the SM status page or on any of the ISLU MCC display pages change while being displayed, the appropriate indicators are updated with the changed status. The 170YZZ page display can be accessed from the 170Y ISLU NETWORK page display. An example of the 170YZZ page is shown in Figure .AW G271/. Included in this example are the ANSI(R) U-Line Cards (AULC) and AULC spare (AUSP). Commands are provided to remove, restore, and diagnose the ISLULGCs and ISLULCs. Any available paging commands can be entered from this page. CMD RESULT 200 Removes ISLULGC (RMV=ISLULGC=a-b-c) 21XX Removes ISLULC XX (RMV=ISLULC=a-b-c-XX) 300 Restores ISLULGC (RST=ISLULGC=a-b-c) 31XX Restores ISLULC XX (RST=ISLULC=a-b-c-XX) 500 Diagnoses ISLULGC (DGN=ISLULGC=a-b-c,RAW,TLP) 51XX Diagnoses ISLULC XX (DGN=ISLULC=a-b-c,RAW,TLP) The 171Y,X page display provides status and menu selection for the maintenance actions of the ISLUMAN, ISLURG, and ISLUHLSC. The last digit of the page number indicates the ISLU number (for example, 1712). The ISLU numbers range from 1710 through 1717. This page (one per ISLU) displays the status of each ISLUHLSC, ISLUMAN, and ISLURG in both SGs 0 and 1. The possible states of these indicators are ACT, CAMP, OOS, OOSFE, DGR, GROW, and UNEQ. When any of the circuits in an ISLU SG are in an off-normal state, the associated SG summary status indicator for that SG is backlighted. The 171Y,X page can be accessed from the 170Y - SM ISLU NETWORK page display. Figure .AW G272/ shows an example of the 171Y,X page display. Commands are provided to remove, restore, and diagnose the ISLUMAN, ISLUHLSC, and ISLURG of the SG. Also, the ISLU Line Group page display can be requested. Any available paging commands can be entered from this page. CMD RESULT 20XY Removes ISLUMAN Y SG X (RMV=ISLUMAN=a-b-x-y) 21XY Removes ISLUHLSC Y SG X (RMV=ISLUHLSC=a-b-x-y) 22X Removes ISLURG SG X (RMV=ISLURG=a-b-x) 30XY Restores ISLUMAN Y SG X (RST=ISLUMAN=a-b-x-y) 31XY Restores ISLUHLSC Y SG X (RST=ISLUHLSC=a-b-x-y) 32X Restores ISLURG SG X (RST=ISLURG=a-b-x) 50XY Diagnoses ISLUMAN Y SG X (DGN=ISLUMAN=a-b-x-y,RAW,TLP) 51XY Diagnoses ISLUHLSC Y SG X (DGN=ISLUHLSC=a-b-x-y,RAW,TLP) 52X Diagnoses ISLURG SG X (DGN=ISLURG=a-b-x) 170YZZ Displays ISLU Y LG ZZ The 1800,X page provides inhibit and recovery status and control information for SM X. It functions like an emergency action interface for the switching module (SM). When an inhibit is requested, the top third of the associated indicator will be backlighted to the INHIBIT state, and the text INH will appear in the corresponding box. When the inhibit is actually activated, the rest of the associated indicator will be backlighted to the INHIBIT state. On Page 114 - EQUIPPED SM STATUS SUMMARY, the indicator for that SM will be backlighted. On the appropriate 141, 142, 143, or 144 page, the indicator for that SM will be backlighted, and the phrase INHIBITS will be written unless a more critical condition exists. In the SUMMARY STATUS AREA, the SM critical indicator will be backlighted. Some of the boxes on the 1800,X page have numbers at the bottom of the box. These numbers show what commands are available from the display. For example, at the bottom of Box 02 the numbers ``6 7 9'' appear. The ``6'' means this item can be inhibited by entering 602, the ``7'' means it can be allowed by entering 702, and the ``9'' means output is available with 902. On color MCC terminals, there is also color mapping from the commands shown on the left of the display to the numbers in the boxes. In addition to the inhibit status indicators, there are indicators for the status of the module controller time slot interchangers (MCTSI) 0 and 1. When the MCTSIs are functioning normally, the active MCTSI is marked active (ACT). If an MCTSI is active forced, it is shown as ACTF and the other MCTSI is marked unavailable (UNAV). The conditions standby and out of service also apply to this display. During an initialization, the status of the inactive MCTSI cannot be precisely determined and the display will be blanked. There is also an indicator for the state of the mate memory. The possible states for the mate memory indicator are as follows: o STANDBY: Mate memory has been updated. o UPDATING: Mate memory update is in progress. o OOD: Mate memory is out of date. o PUMPED: Mate memory has been off-line pumped. During an initialization, the status of the mate memory cannot be precisely determined and the display will be blanked. The lower area of the SM STAT indicator is for listing special abnormal conditions in the SM. The possible conditions shown in this area are as follows: GEN DIFF, ISOLATED, COMMLOST, SPEC GROW, STNDALONE, INIT PEND, and HASH ERR. This section describes the individual indicators and their behavior. Box 00 Routine Audits This indicator shows if the automatic execution of the SM audit cycle is inhibited. Entering the 600 command generates the command INH:AUD=CYCLE,SM=X and causes the top line of the indicator to be backlighted and the text INH to be written. This request is phase-protected. Single audits can also be inhibited via input messages, but they are not phase-protected. When the request is recorded, the description area of the box is backlighted. This area is backlighted if one or more of the SM audits are inhibited. Entering the command 700 generates the command ALW:AUD=CYCLE,SM=X and causes the indicator to return to normal video. The command 900 can be entered to get a ROP listing of routine audit status for the SM. This command generates the message OP:STATUS=ALL,AUD,SM=X. Box 01 Auto Pump When the 601 command is entered, it generates the command INH:PUMP,SM=X. This inhibits the automatic pump of the SM on a major initialization (except UNIX RTR system level D4). This inhibit is phase-protected. The 701 command generates ALW:PUMP,SM=X. This command must be entered to cancel the inhibit. Box 02 Routine Exercises This indicator shows if any or all of the routine exercises (other than unit exercises) in the SM are inhibited. Entering the command 602 generates the message INH:REX,SM=X. Entering the command 702 generates the message ALW:REX,SM=X. To print a status listing of routine exercises at the ROP, enter the 902 command (OP:REXINH,SM=X). Box 03 Manually Isolate When the 403 command is entered, it generates the message SET:ISOL,SM=X. This configures CLNK hardware to remove any level 2 protocol or active links from service. The removal is unconditional, and the SM will remain isolated until the 503 command is entered which generates the message CLR:ISOL,SM=X. Box 04 Software Checks This indicator reflects whether or not the AM application software checks are inhibited. If any software checks have been inhibited, the description section is backlighted. The command 604 generates the message INH:SFTCHK,SM=X and 704 generates ALW:SFTCHK,SM=X. Box 05 Sanity Timer This box provides commands to inhibit and allow the sanity timer. The command 605 generates the message ORD:CPI=X,CMD=INH and 705 generates ORD:CPI=X,CMD=ALW. Box 06 CORC Logging The command 606 generates the message INH:CORCLOG,SM=X which causes the Customer-Originated Recent Change (CORC) logging to be inhibited. Inhibiting customer-originated recent change logging should only be used when recent change logging is suspected to be causing a problem in the system. The command 706 generates the message ALW:CORCLOG,SM=X. Box 07 Recent Change Backout This indicator shows the status of recent change (RC) backout. If set, RCs will not be reentered following a high-level initialization. The description portion shows when the recent changes are actually backed out or loaded. If the backout is in progress, a number will appear on the third line of the box showing the progress of the backout. From 200 down to 100 is CORC backout; 200 meaning CORC is still fully backed out, and 100 meaning CORC is fully rolled forward. From 100 down to 0 is RC backout; 100 meaning RC is still fully backed out, and 0 meaning RC is fully rolled forward. Recent changes can be backed out only in conjunction with a high-level initialization. The command 407 generates the message SET:BACKOUT,RC,SM=X and 507 generates CLR:BACKOUT,RC,SM=X. Box 08 Hardware Checks The command 608 (INH:HDWCHK,SM=X) causes all SM hardware checks to be inhibited. Note: The lower portion of this box is lighted only if all hardware checks have been inhibited. If hardware checks are allowed circuit by circuit, the indicator will not be cleared. The command 708 (ALW:HDWCHK,SM=X) allows all SM hardware checks. This will clear the backlighting of the box. Box 09 SM Brevity Controls Certain messages are normally suppressed from printing at the ROP. By inhibiting the controls, all SM output messages would be sent to the AM regardless of past message counts. Using this command can increase link traffic to the AM, and thus, can be service affecting. Inhibiting the brevity controls is achieved by entering command 609 (INH:BREVC,SM=X). The controls can be returned to normal by entering the command 709 (ALW:BREVC,SM=X). Box 10 UPD Backout This indicator shows whether or not recently applied SM program updates are currently loaded or backed out. The description portion shows when the program updates are actually backed out or loaded. Program updates can be backed out or loaded only in conjunction with a high-level initialization. There are no menu commands for this box. Box 11 Min Mode (Full Init) This inhibit causes the SM to enter minimum mode and ignore all call processing. This inhibit should only be used in extreme emergencies, when all other normal recovery procedures have failed. When the 411 command is entered, the message SET:MINMODE,SM=X,FI is sent. This initiates a high-level init and inhibits software checks, hardware checks, routine exercises, and routine audits. In addition, output message brevity control is allowed. The only way to exit min mode is to enter the clear command or message. The 511 command generates the message CLR:MINMODE,SM=X,FI and causes a high-level init. Box 12 Peripheral Fault Recovery Message Verbose The command 412 (SET:PERPH,SM=X, VERBOSE) causes peripheral fault recovery (PFR) to send to the AM peripheral error messages that indicate that no recovery action has occurred in addition to messages that indicate that a peripheral error has caused recovery actions. The command 512 (CLR:PERPH,SM=X, VERBOSE) causes PFR to suppress the output of error reports. In the normal state, only output messages which indicate that a peripheral error has caused recovery actions on a circuit will be output. The messages will be logged or printed, depending on the state of the message class for each peripheral unit type. Box 13 Alarmed Message Discard This indicator shows if any output messages for this SM are being discarded. Output messages of CRITICAL, MAJOR, MINOR, or MANUAL can be discarded by the input message CHG:MSGCNTL. When this input message is entered, the box will be backlighted. Boxes 14 - 15 - Boxes 14 - 15 are currently not used. Figure .AW G273/ is an example of the 1800,X page which shows the SM 1 sanity timer inhibited; MCTSI 0 is active and MCTSI 1 is in standby. The mate memory is out of date and 50 percent of the recent change has been backed out. Any available paging command can be entered from the 1800,X display page. Input messages for commands shown in boxes on the display are also described previously under the subheading, Indicators. 2 CMD RESULT 403 Manual Isolation of SM is set (SET:ISOL,SM=xxx) 407 RC Backout is set (SET:BACKOUT,RC,SM=$S) 411 Min Mode (FI) is set (SET:MINMODE,SM=$S,FI) 412 Peripheral fault recovery message verbose is set (SET:PERPH,SM=$S,VERBOSE) 420 MCTSI 0 is forced active (SET:MCTSI=XX-0,FRC) 421 MCTSI 1 is forced active (SET:MCTSI=XX-1,FRC) 422 Force of MCTSI is cleared (CLR:MCTSI=XX,FRC) 503 Manual Isolation of SM is cleared (CLR:ISOL,SM=$S) 507 RC Backout is cleared (CLR:BACKOUT,RC,SM=$S) 511 Min Mode (FI) is cleared (CLR:MINMODE,RC,SM=$S,FI) 512 Peripheral fault recovery message verbose is cleared (CLR:PERPH,SM=$S,VERBOSE) 600 Routine Audits are inhibited (INH:AUD=CYCLE,SM=$S) 601 Auto Pump is inhibited (INH:PUMP,SM=$S) 602 Routine Exercises are inhibited (INH:REX,SM=$S) 604 Software Checks are inhibited (INH:SFTCHK,SM=$S) 605 Sanity Timer is inhibited (ORD:CPI=$S,CMD=INH) 606 CORC Logging is inhibited (INH:CORCLOG,SM=$S) 608 All Hardware Checks are inhibited (INH:HDWCHK,SM=$S) 609 Brevity Control for the SM is inhibited (INH:CREVC,SM=$S) 700 Routine Audits are allowed (ALW:AUD=CYCLE,SM=$S) 701 Auto Pump is allowed (ALW:PUMP,SM=$S) 702 Routine Exercises are allowed (ALW:REX,SM=$S) 704 Software Checks are allowed (ALW:SFTCHK,SM=$S) 705 Sanity Timer is allowed (ORD:CPI=$S,CMD=ALW) 706 CORC Logging is allowed (ALW:CORCLOG=$S,) 708 All Hardware Checks are allowed (ALW:HDWCHK,SM=$S) 709 Brevity Control for the SM is allowed (ALW:BREVC,SM=$S) 900 Routine Audits are output (OP:STATUS=ALL,AUD,SM=$S) 902 Routine Exercises are output (OP:REXINH,SM=$S) 920 Selective initialization is requested (INIT:SM=X,SI) 921 Selective initialization with pump is requested (INIT:SM=X,SI,PUMP) 922 Full Initialization is requested (INIT:SM=X,FI) 923 Full Initialization with pump is requested (INIT:SM=X,FI,PUMP) 924 Forces the reset counter to level 12 or greater (guaranteeing a high-level init). This poke does not require software sanity in the SM. Poke 924 uses central processor intervention (CPI) to force the SM to reset, and the ROM reset handler forces the reset count to level 12 or greater. The remainder of the init occurs normally (ORD:CPI=X,CMD=RESET). Note: If the SM fails to respond to the FI PUMP and the SM appears to have lost sanity, use MP RESET (924 poke). Also, if the SM is attempting to pump and is failing, then MP RESET may not help. The 1850 page provides status displays for both the primary and mate CMPs of the pair. Also provided are menu commands to inhibit or allow hardware and software checks, routine audits, automatic pump, brevity control, and set and clear for recent change backout. Requests for high-level initialization can be poked from the 1850 page. On the 1850 page display, each processor is identified by its CMP pair number and by its physical representation which includes the message switch side. There is only one primary/mate CMP pair (0) for 5E6. During CMP initialization, the initialization status phrase progress marks will be displayed in the PRIM STAT portion of the screen along with the progress counter which shows the progress within a particular phase of the initialization. The set of progress marks used will be different from the set used for the SMs pump and initialization sequences on MCC Page 1800,X. Table .AW TAI/ shows the CMP Off-Normal Status Phrases along with the priority, color, and an explanation of each. After initialization has completed, the current (highest) level CMP status will be displayed (just as with the SMs on the 1800,X page). A ``+'' sign at the end of the status phrase indicates that more than one off-normal status exists. The OP:SYSTAT input message or 800 poke command can be used to obtain additional off-normal status information. Also, the current (highest) status of the MATE CMP will be displayed. Additional status phrases are displayed in the other PRIM STAT and MATE STAT boxes along with the peripheral control data (PCD) status. Some of the boxes on the 1850 page have numbers at the bottom. These numbers show what commands are available from the display. For example, at the bottom of Box 00 the numbers ``6 7 9'' appear. The ``6'' means this item can be inhibited by entering 600, the ``7'' means it can be allowed by entering 700, and the ``9'' means output is available with 900. On color MCC terminals, there is also color mapping from the commands shown on the left of the display to the numbers in the boxes. This section describes the individual indicators and their behavior. Box 00 - Routine Audits This indicator shows if the automatic execution of the CMP audit cycle is inhibited. Entering the 600 command generates the command INH:AUD[=a],CMP=b and causes the top line of the indicator to be backlighted and the text INH to be written. This request is phase-protected. Single audits can also be inhibited via input messages, but they are not phase-protected. When the request is recorded, the description area of the box is backlighted. This area is backlighted if one or more of the CMP audits are inhibited. Entering the command 700 generates the command ALW:AUD[=a],CMP=b and causes the indicator to return to normal video. The command 900 can be entered to get a ROP listing of routine audit status for the CMP. This command generates the message OP:STATUS[=a],AUD[=b],CMP=c. Box 01 - Auto Pump When the 601 command is entered, it generates the command INH:PUMP,CMP=a. This inhibits the automatic pump of the CMP on a major initialization (except UNIX RTR system level D4). This inhibit is phase-protected. The 701 command generates ALW:PUMP,CMP=a. This command must be entered to cancel the inhibit. Boxes 02 and 03 - Boxes 02 and 03 currently are not used. Box 04 - Software Checks This indicator reflects whether or not the AM application software checks are inhibited. If any software checks have been inhibited, the description section is backlighted. The command 604 generates the message INH:SFTCHK,CMP=a and 704 generates ALW:SFTCHK,CMP=a. Box 05 - Alarmed Messages Discarded The input message, CHG:MSGCNTL,CMP=a (where a is the CMP pair number), is associated with box 05. This box will also backlight to indicate some type of alarmed messages (CRITICAL, MAJOR, MINOR, or MANUAL) are being discarded. Box 06 - Box 06 is currently not used. Box 07 - Recent Change Backout This indicator shows the status of recent change (RC) backout. If set, RCs will not be reapplied following a full initialization. The description portion shows when the recent changes are actually backed out or applied. A number indicating the status of a backout in progress will appear on the third line of the box. From 200 down to 100 is CORC backout; 200 meaning CORC is still fully backed out, and 100 meaning CORC is fully rolled forward. From 100 down to 0 is RC backout; 100 meaning RC is still fully backed out, and 0 meaning RC is fully rolled forward. Recent changes can be backed out only in conjunction with a full initialization. The command 407 generates the message SET:BACKOUT,RC,CMP=a and 507 generates CLR:BACKOUT,RC,CMP=a. Box 08 - Hardware Checks The command 208 (INH:HDWCHK,CMP=a) causes all CMP hardware checks to be inhibited. The lower portion of this box is lighted only if all hardware checks have been inhibited. If hardware checks are allowed circuit by circuit, the indicator will not be cleared. The command 308 (ALW:HDWCHK,CMP=a) allows all CMP hardware checks. This will clear the backlighting of the box. Box 09 - CMP Brevity Controls Certain messages are normally suppressed from printing at the ROP. By inhibiting the controls, all CMP output messages would be sent to the AM regardless of past message counts. Using this command can increase link traffic to the AM, and thus, can be service affecting. Inhibiting the brevity controls is achieved by entering command 609 (INH:BREVC,CMP=a). The controls can be returned to normal by entering the command 709 (ALW:BREVC,CMP=a). Box 10 - UPD Backout This indicator shows whether or not recently applied CMP program updates are currently applied or backed out. The description portion shows when the program updates are actually backed out or applied. Program updates can be backed out or applied only in conjunction with a full initialization. There are no menu commands for this box. Box 11 - Min Mode This box is used to display whether or not the AM/CMPs are in minimum mode. The CMP 0 PRIM STAT box located in the top-middle portion of the screen can be updated with vartext for internal indicators. This box contains three subboxes: 1. Top PRIM STAT box: Left half is logical link map designation (0-0 or 1-0) and right half is PCD status. 2. Middle PRIM STAT box: Contains three lines of information: o Initialization phrases and highest priority status phrases for PRIM CMP o Initialization progress counter o Initialization phrase trigger. 3. Bottom PRIM STAT box: Contains four lines: o HASH ERR o GEN DIFF o SPEC GROW (Not Used) o COMM LOST. The MATE STAT box, located in the lower middle portion of the screen, contains two subboxes: 1. Top MATE STAT box: The left half contains the logical link map designation (0-0 or 1-0) for the MATE CMP. The right half displays the PCD status of the MATE CMP. 2. Bottom MATE STAT box: Contains initialization and status phrases for the MATE CMP. Figure .AW G274/ shows an example of the 1850 display page. Any available paging command can be entered from the 1850 display page. All 600 and 700 level pokes are duplex commands which can only be entered from the primary (PRIM) CMP page (1850). 2 CMD RESULT 208 Inhibits hardware checks of CMP (INH:HDWCHK,CMP=a,PRIM) 308 Allows hardware checks of CMP (ALW:HDWCHK,CMP=a,PRIM) 407 Backout uncommitted recent changes of CMP (SET:BACKOUT,RC,CMP=a,PRIM) 507 Clears recent changes from a CMP (CLR:BACKOUT,RC,CMP=a,PRIM) 600 Audit cycle inhibited for CMPs (INH:AUD[=a],CMP=b) 601 Inhibits automatic pump of CMPs on full initialization (INH:PUMP,CMP=a) 604 Inhibits software error checks of CMPs (INH:SFTCHK,CMP=a) 609 Inhibits automatic brevity control for CMPs (INH:BREVC,CMP=a) 700 Audit cycle allowed for CMPs (ALW:AUD[=a],CMP=b) 701 Allows automatic pump of CMPs (ALW:PUMP,CMP=a) 704 Allows software error checks in CMPs (ALW:SFTCHK,CMP=a) 709 Allows automatic brevity control for CMPs (ALW:BREVC,CMP=a) 800 Requests off-normal reports for CMP status (OP:SYSSTAT,CMP=a) 900 Requests audit status for CMP (OP:STATUS[=a],AUD[=b],CMP=c,PRIM) 919 Requests purging initialization of selected CMP (INIT:CMP=a,PRIM,PGI) 920 Requests selective initialization of selected CMP (INIT:CMP=a,PRIM,SI) 922 Requests full initialization of selected CMP (INIT:CMP=a,PRIM,FI) 923 Requests full initialization and pump of selected CMP (INIT:CMP=a,PRIM,FI,PUMP) The 1851 page is similar to the 1850 except that 600 and 700 level pokes cannot be entered from the 1851 page. Also, the 1851 page has the 930 and 931 commands that the 1850 does not have. The 1851 page provides status displays for both the primary and mate CMP pair. Also provided are menu commands to inhibit or allow hardware and software checks, routine audits, automatic pump, brevity control, and set and clear for recent change backout. Requests for full initialization can be poked from the 1851 page. On the 1851 page display, each processor is identified by its CMP pair number and by its physical representation which includes the message switch side. There will be only one primary/mate CMP pair (0) for 5E6. During CMP initialization, the initialization status phrase progress marks will be displayed in the PRIM STAT portion of the screen along with the progress counter which shows the progress within a particular phase of the initialization. The set of progress marks used will be different from the set used for the SMs pump and initialization sequences on MCC Page 1800,X. Table .AW TAJ/ shows the CMP Off-Normal Status Phrases along with the priority, color, and an explanation of each. After initialization has completed, the current (highest) level CMP status will be displayed (just as with the SMs on the 1800,X page). A ``+'' sign at the end of the status phrase indicates that more than one off-normal status exists. The OP:SYSTAT input message or 800 poke command can be used to obtain additional off-normal status information. Also, the current (highest) status of the primary CMP will be displayed. Additional status phrases are displayed in the other PRIM STAT and MATE STAT boxes along with the PCD status. Some of the boxes on the 1851 page have numbers at the bottom. These numbers show what commands are available from the display. For example, at the bottom of Box 00 the number ``9'' appears. The ``9'' means output is available by entering 900. On color MCC terminals, there is also color mapping from the commands shown on the left of the display to the numbers in the boxes. This section describes the individual indicators and their behavior. Box 00 - Routine Audits This indicator shows if the automatic execution of the CMP audit cycle is inhibited. The command 900 can be entered to get a ROP listing of routine audit status for the CMP. This command generates the message OP:STATUS[=a],AUD[=b],CMP=c. Box 01 - Auto Pump Commands to allow or inhibit automatic pump of the CMP must be entered from Page 1850. Boxes 02 and 03 - Boxes 02 and 03 currently are not used. Box 04 - Software Checks Commands to allow or inhibit software checks of the CMP must be entered from Page 1850. Box 05 - Alarmed Messages Discarded The input message, CHG:MSGCNTL,CMP=a (where a is the CMP pair number), is associated with box 05. This box will also backlight to indicate some type of alarmed messages (CRITICAL, MAJOR, MINOR, or MANUAL) are being discarded. Box 06 - Box 06 is currently not used. Box 07 - Recent Change Backout This indicator shows the status of recent change (RC) backout. If set, RCs will not be reapplied following a full initialization. The description portion shows when the recent changes are actually backed out or applied. If the backout is in progress, a number will appear on the third line of the box showing the progress of the backout. From 200 down to 100 is CORC backout; 200 meaning CORC is still fully backed out, and 100 meaning CORC is fully rolled forward. From 100 down to 0 is RC backout; 100 meaning RC is still fully backed out, and 0 meaning RC is fully rolled forward. The RCs can be backed out only in conjunction with a full initialization. The command 407 generates the message SET:BACKOUT,RC,CMP=a and 507 generates CLR:BACKOUT,RC,CMP=a. Box 08 - Hardware Checks The command 208 (INH:HDWCHK,CMP=a) causes all CMP hardware checks to be inhibited. Note: The lower portion of this box is lighted only if all hardware checks have been inhibited. If hardware checks are allowed circuit by circuit, the indicator will not be cleared. The command 308 (ALW:HDWCHK,CMP=a) allows all CMP hardware checks. This will clear the backlighting of the box. Box 09 - CMP Brevity Controls Commands to allow or inhibit brevity control must be entered from Page 1850. Box 10 - UPD Backout This indicator shows whether or not recently applied CMP program updates are currently applied or backed out. The description portion shows when the program updates are actually backed out or applied. Program updates can be backed out or applied only in conjunction with a full initialization. There are no menu commands for this box. Box 11 - Min Mode This box is used to display whether or not the AM/CMPs are in minimum mode. The MATE STAT box located in the top-middle portion of the screen can be updated with vartext for internal indicators. This box contains three subboxes: 1. Top MATE STAT box: Left half is logical link map designation (0-0 or 1-0) and right half is PCD status. 2. Middle MATE STAT box: Contains three lines of information: o Initialization phrases and highest priority status phrases for MATE CMP o Initialization progress counter o Initialization phrase trigger. 3. Bottom MATE STAT box: Contains four lines: o HASH ERR o GEN DIFF o SPEC GROW (Not Used) o COMM LOST. The PRIM STAT box, located in the lower middle portion of the screen, contains two subboxes: 1. Top PRIM STAT box: The left half contains the logical link map designation (0-0 or 1-0) for the PRIM CMP. The right half displays the PCD status of the PRIM CMP. 2. Bottom PRIM STAT box: Contains initialization and status phrases for the PRIM CMP. Figure .AW G275/ shows an example of the 1851 display page. Any available paging command can be entered from the 1851 display page. 2 CMD RESULT 208 Inhibits hardware checks of CMP (INH:HDWCHK,CMP=a,MATE) 308 Allows hardware checks of CMP (ALW:HDWCHK,CMP=a,MATE) 407 Backout uncommitted recent changes of CMP (SET:BACKOUT,RC,CMP=a,MATE) 507 Clears recent changes from CMP (CLR:BACKOUT,RC,CMP=a,MATE) 800 Requests off-normal reports for CMP status (OP:SYSTAT, CMP=a) 900 Requests audit status for CMP (OP:STATUS[=a],AUD[=b],CMP=c,MATE) 919 Requests purging initialization of selected CMP (INIT:CMP=a,MATE,PGI) 920 Requests selective initialization of selected CMP (INIT:CMP=a,MATE,SI) 922 Requests full initialization of selected CMP (INIT:CMP=a,MATE,FI) 923 Requests full initialization and pump of selected CMP (INIT:CMP=a,MATE,FI,PUMP) 930 Start off-line pump for specified mate CMP (ST:OPUMP,CMP=a,MATE) 931 Stop off-line pump for specified mate CMP (STP:OPUMP,CMP=a,MATE) The purpose of the 1900,X page is to show status and to provide maintenance controls for SM X communication links (CLNKs). The 1900,X page shows the status of each CLNK to SM X and the status of the supporting hardware. A CLNK path includes the office network timing complex (ONTC 0 or 1), the module message processor (MMP 0 or 1), and the message switch (MSGS 0 or 1). The CLNK numbers are derived from the hardware path. The first digit is the ONTC number, the second is the MMP, and the third is the MSGS. Figure .AW G276/ is an example of the CM2 version of the 1900,X page. The status of the SM's dual link interfaces (DLI) is also displayed. For a remote switching module (RSM), the host switching module (HSM) number and the status of the HSM's DLIs are displayed. Figure .AW G277/ is an example of the RSM version of Page 1900,X. If the SM is an optically remoted module (ORM), the transmission rate converter unit (TRCU) hardware is identified in the ONTCCOM/DLI indicator block. This indicator does not show the status of the TRCU hardware. Figure .AW G278/ is an example of the ORM version of Page 1900,X. Two logical communication paths (0 and 1) are assigned dynamically to in-service physical links. Physical CLNKs that are supporting a logical link are shown as active (ACT). The logical to physical link assignments are displayed, along with the state of each physical link. The CLNKs that are not active will usually be in the IDLE state. This means that they are available if an active CLNK goes out of service (OOS), but would need to be configured before becoming active. The RSM CLNKs may be in the standby (STBY) state. A STBY CLNK has already been configured, and will be made active if an ONTC switch occurs. Active RSM CLNKs must pass through the major ONTC. The SM X STAT indicator on the display contains one of the SM summary status phases, as listed in the table following the description of Page 114 - EQUIPPED SM STATUS SUMMARY. The CLNK-related off-normal conditions (OOS, simplex, or inhibited links) can cause the SM status to become ``CLNK OFFN.'' When such an off-normal condition exists, indicators for the affected units will backlight. On Page 115 - COMMUNICATION MODULE SUMMARY, the CLNK indicator will backlight. On Page 1260 - CLNK SUMMARY, the appropriate SM indicator will backlight. If the SM is isolated, the CLNK indicator on Page 1260 will be flashing. In the SUMMARY STATUS AREA, the SM and CM critical indicators and the alarm level (CRITICAL, MAJOR, or MINOR), if any, will backlight. The 1900,X page differs slightly based on the communication module hardware vintage (CM1 or CM2). For CM1, the note at the lower left of the display defining ONTCCOM will include the link interface (LI). This unit does not exist in CM2 offices. The status of 8 CLNKs and 4 MMPs (two per MSGS side) will be displayed in offices equipped with dual MMPs. Otherwise, only 4 CLNKs and 2 MMPs will be shown. Figure .AW G279/ is an example of the CM1 version of Page 1900,X. The 1900,X page provides commands to remove, restore, inhibit, allow, and output the configuration status of the communication links. In addition, any available paging command can be entered from this display. CMD RESULT 2XXX CLNK XXX is removed (RMV:CLNK=SM#-X-X-X) 3XXX CLNK XXX is restored (RST:CLNK=SM#-X-X-X) (If a conflicting CLNK is already active, the restore will leave the designated CLNK in the IDLE or STBY state, not ACT. If the designated CLNK is already OOSF, the restore request will leave it in the OOSF state.) 6XXX CLNK XXX hardware checks are inhibited (INH:HDWCHK,CLNK=SM#-X-X-X) 7XXX CLNK XXX hardware checks are allowed (ALW:HDWCHK,CLNK=SM#-X-X-X) 9XXX Configuration status for CLNK XXX is output (OP:CFGSTAT,CLNK=SM#-X-X-X) The purpose of Page 1940 is to provide a simplified procedure for installing Broadcast Warning Messages (BWM) into the 5ESS switch. The EASY BWM feature simplifies the BWM application process by freeing the user from entering commands and constantly having to monitor the progress of the BWM. The Easy BWM Installation page can be used to back out, install, or apply BWMs with a single command. The page also provides control of the soak interval timer. This user specified time will override the 24-hour default value. Several terms used in the commands which may be confusing are described as follows: o Install: To take an official BWM from the start command to the official command. The TEMP BWMs cannot be made official. o Back Out: To take a TEMP or craft BWM that is soaking and back it out of the system. o Apply: To take a TEMP or craft BWM from the start command to the soak command. o Soak: To leave a BWM in the system for a certain period of time so as to allow the update to have a chance to interact with other pieces of software in the system. o Official: To make a BWM permanent in the system. The 1940 page (Figure .AW G280/) is divided into two basic areas. The area in the middle of the page contains the poke commands used to control the BWM processes. These poke commands are discussed in the ``Commands'' paragraph. The area at the bottom of the page will provide a response indicating the progress of a BWM procedure or a summary of an error message if an error occurs during the execution of a command. Also found in the bottom area are the names of the Install, Back Out, and Apply BWMs in addition to the value of the BWM Soak Interval Timer. Whenever Page 1940 is displayed, the values for Install BWM Name, Back Out BWM Name, Apply BWM Name, and BWM Soak Interval Timer will be populated with default information. The following describes each of these fields in detail. The Install BWM Name is the name of the BWM that should be inputed into the switch. The Install BWM Name can be changed with the 9810 poke command. The Back Out BWM Name is the name of the TEMP/craft BWM to be backed out before the next BWM is to be installed/applied. If no BWM is in the soak state, the default value NONE will be displayed. To change the name of the BWM to be backed out, use the 9820 poke command. The Apply BWM Name is the name of the TEMP/craft BWM to be applied after the Install BWM is in the official state. This field always defaults to the value NONE. To change the name of the BWM to be applied, use the 9830 poke command. The BWM Soak Interval Timer is defaulted to 24 hours 00 minutes. This field will always be displayed. If the value needs to be changed, use the 9840 poke command. The middle of Page 1940 provides commands used to process BWMs. These commands are as follows: CMD RESULT 9800 Start Execution 9810,(Y) Change Install BWM Name 9820,(Y) Change Back Out BWM Name 9830,(Y) Change Apply BWM Name 9840,HH,MM Change BWM Soak Interval Timer 9850,F Dump Inst BWM File 9860 Stop Execution 9870 Stop After Soak The 9800 poke command starts the execution of the EASY BWM process. If the back out BWM is populated with a BWM name, it backs out that BWM, then it installs the install BWM, and if appropriate, applies the apply BWM. This poke command must not be entered before the install BWM name is populated (9810 poke command) with a valid BWM name. After execution is started on the 1940 page and its response line states that EASY BWM IS IN PROGRESS, the page is not updated until it completes successfully or runs into a failure. To find out the current status of BWMs look on Page 1960. The 1960 page is kept up to date while the EASY BWM process is executing. The 9810 poke command populates the Install BWM Name. This BWM is the one which will be used as the install BWM. This field can contain any valid 6- or 10-character BWM name. This field MUST be populated for the EASY BWM process to work. If this BWM name is a TEMP BWM, then this BWM will not be made official and the Apply BWM will NOT be applied to the 5ESS switch. The 9810 poke command should always be the first poke command entered on the page. This is needed since this poke command initializes the page with default information, except for the data just entered. If the page is set up and this is the last poke command executed, the page will be initialized and the previous input will have to be reentered. The 9820 poke command will populate the Back Out BWM Name. This BWM is the one which will be backed out of the 5ESS switch when execution is started. This field is populated for the user and should never have to be changed by the user. This field can contain all valid BWM names except official BWMs (BWMs that start with BWM). The 9830 poke command will populate the Apply BWM Name. This BWM is the one that will be applied after the Install BWM is finished. This will NOT happen if the Install BWM is a TEMP BWM. In that case, the Apply BWM will NOT be applied to the 5ESS switch. This field can contain all valid BWM names except official BWMs (BWMs that start with BWM). The 9840 poke command will allow the user to change the soak interval timer for the Install BWM. Default value for the timer is 24 hours and 00 minutes. The timer does not change until the soak section has been executed and the timer set. At that time the EASY BWM process resets the soak interval timer to the value the user entered. The 9850 poke command will print (on the ROP) any American standard code for information interchange (ASCII) file associated with the Install BWM. This includes the MSGS and SCANS files. To print the MSGS file for the Install BWM with this command, you would enter 9850,MSGS. The 9860 poke command will stop the execution of all commands on Page 1940 (see example outlined as follows). Execution will be stopped only after the current step in the current state is completed. This command is the same as the 9560 poke command on Page 1960. The 9870 poke command allows the user to stop the execution of the EASY BWM process after the Install BWM has started its soak section. If this option is selected, the 9870 poke must have been entered causing the STOP AFTER SOAK status field to show ON, and the execution of EASY BWM will stop awaiting user input. To restart the EASY BWM process, reenter the 9800 poke. If the 9870 poke was not entered, the STOP AFTER SOAK status field will show OFF, and the EASY BWM process will not stop until execution has completed in full. Note that the 9870 poke toggles the STOP AFTER SOAK option, so that if it was ON, entering the 9870 poke will cause it to turn OFF. Also, if it was OFF, entering the 9870 poke will cause it to turn ON. An example using the 1940 page follows. For this example, assume: o TEMP BWM TMP88-6082 is soaking. o Official BWM BWM88-0050 is to be installed. o TEMP BWM TMP88-6089 is to be applied after the install BWM has finished. o A soak time of 2 hours and 0 minutes is wanted for the Install BWM. The following is a list of steps that the user would take to accomplish this example: ACTION RESULT 1. Enter the 1940 poke command. The 1940 page is displayed. The Back Out BWM field is populated with TMP88-6082, the rest of the page contains default information. 2. Enter the 9810,880050 poke command. The Install BWM field is populated with BWM88-0050. 3. Enter the 9830,886089 poke command. The Apply BWM field is populated with TMP88-6089. 4. Enter the 9840,2,0 poke command. This will populate the soak interval timer with 2-00. 5. Enter the 9800 poke command. This will start execution of the EASY BWM process. The 1950 display page provides commands to display BWM history, to recover backward and forward, to clear the BWM, and to back out the last official BWM. The soak period for a BWM can be set/changed by the craft (poke 9700); the poke 9710 can be used to check the status of a specific BWM soak period; the poke 9720 can be used to abort soak timer. PROGRAM UPDATE keeps an on-line log of the history of all BWMs installed against the current software release issue in a 5ESS switch office. The 9101,Y - BWM Y command causes the history of the specified BWM (Y = BWM name) to be printed at the ROP. 9102 - OFC causes a history of all the BWMs, which have been made official, to be printed at the ROP. 9103 - TEMP causes a history of all of the BWMs which are in the temporary state to be printed at the ROP. 9104 - ALL causes the history of all BWMs in the active log to be printed at the ROP. This command can also accept the COMMAND,DATA! format. This is provided for 9104,BACKLOG which would print the history of all the BWMs in an archive log, and 9104, SUM which prints a short summary of the BWMs. 9200 - VERIFY INCONSISTENCY causes any update inconsistencies to be detected and printed at the ROP. 9300 - RECOVER FORWARD reapplies all the temporary updates which are in the table of inconsistencies. 9400 - RECOVER BACKWARD removes all the temporary updates causing inconsistencies starting from the very last one in the system to the first. 9600,Y - CLEAR BWM Y causes the files in the specified BWM package (Y = BWM name) to be removed. (Used to free up disk space after the BWM is made official.) 9650,X - EXPAND BWM causes the compressed files in the specified BWM package (X=BWM name) to be expanded. (Used to expand a compressed BWM when the automatic expansion during a BWM download through SCANS or CSCANS was manually stopped or aborted.) 9700,HH,MM - RESET TIMER to ``HH'' HOURS and ``MM'' MINUTES has two applications as follows: a. Make BWM official immediately: The craft can make the BWM official immediately by entering the 9700,0,0 poke command after all of the commands have been executed via the soak poke command (9320 or 9420 on Page 1960). This command allows the craft to bypass the soak period. b. Change time period of the soak: After the craft has initialized the BWM soak period (via poke 9320 or 9420 on Page 1960), the time period of the soak can be changed by entering the 9700,HH,MM poke command. The time period of the soak can only be changed after the soak period has been initialized. If this occurs, the craft receives an error message indicating the soak has not been initialized. Only one BWM can have its soak period set/changed at a time. 9710 - PRINT TIMER INFORMATION (including completion time, start time, and if applicable, the time the soak period was changed) on the ROP. 9720 - ABORT SOAK TIMER aborts the time that was reset previously. 9900 - BACKOUT OFC backs out the last official BWM. The name of the last official BWM is displayed on this display page in the ``LAST OFC BWM'' field. Figure .AW G281/ is an example of the 1950 page which shows that the display of the history of BWM90-0067 has been completed. The entire 1950 display page is commands. In addition to these, any available paging commands can be entered from the 1950 display page. 2 CMD RESULT 9101,Y Displays the history of BWM Y (UPD:UPDDSPLY:BWM=Y) 9102 Displays the history of all official BWMs (UPD:UPDDSPLY,OFC) 9103 Displays the history of all BWMs in the temporary state (UPD:UPDDSPLY,TEMP) 9104 Displays the history of all BWMs in the active log or archive log (UPD:UPDDSPLY,ALL) [,BACKLOG] this displays the archive log BWM history [,SUM] this displays a summary consisting of the last official software update (BWMyy-nnnn), a list of active craft software updates (CFTyy-nnnn), and the temporary software update (TMPyy-nnnn), if one exists, and their respective status 9200 Displays any update inconsistencies (UPD:VFYCON) 9300 Reapplies all the temporary updates considered causing inconsistencies (UPD:RECOVERY,FRWD) 9400 Removes all the temporary updates causing inconsistencies (UPD:RECOVERY,BKWD) 9600,Y Removes the files in the specified BWM (or ALL for all BWMs) (UPD:CLRBWM:BWM=Y | ALL) 9650,X Expands the compressed files in the specified BWM (or STOP to stop automatic expansion for the BWM that is currently being downloaded through SCANS or CSCANS) (UPD:EXPAND:UPNM=Y | STOP) 9700,HH,MM Resets timer for soak period to HH (HH = hour) and MM (MM = minutes) (UPD:RESET:TM=HH-MM) 9710 Prints timer information (completion time, start time, and if applicable, the time the soak period was changed is printed on the ROP) (UPD:PRINT:SKTM) 9720 Aborts soak timer (UPD:RESET:ABORT) 9900 Backs out last BWM that was made official (UPD:BOLO). The purpose of the 1960 display page is to provide commands for installing BWMs and to provide the status of the installation. The 1960 display consists of two parts. The upper part consists entirely of commands. The commands provide the ability to verify a BWM, display or print the contents of the message file in the BWM, or execute commands in the message file. The lower part of the display is the message file display area. The message file is a file in a BWM package which contains a set of craft input messages grouped in sections describing how to install the BWM. There are up to ten numbered lines for displaying the command lines of the message file. The craft can select and print the American standard code for information interchange (ASCII) files [via poke command 9260,F (F = Filename in BWM)] that are associated with a particular BWM on the ROP. If the requested file is not an ASCII file, an error message is printed on the ROP. The 9010 - VERIFY command has a status indicator to its right which will show the status of the verification if 9010 has been entered. The three possible phrases for the status indicator are in progress (INPG), complete (CMPL), and abort (ABRT). If verifying the BWM fails, further information will be printed on the ROP. The SECTION EXECUTION STATUS area provides status indicators for each of the execution sections, except FILE, (that is, APPLY, SOAK, OFC, and BKOUT). If there is an error, the status indicator of the section which was executing will show the status ABRT and be backlighted. The error causing command line in the message file display area will also be backlighted (black on red for color terminals). An additional indicator -- timer in progress (TMPG) is displayed in the SOAK indicator block after soak timer is set. If all the command lines in the section being executed are successful, the status CMPL will be displayed in the appropriate status indicator (that is, APPLY=CMPL, SOAK=CMPL, and OFC=INPG) in the SECTION EXECUTION STATUS area. The RESPONSE indicator is used to display a summary of an error message if an error occurs during the execution of a command line. Further information can always be found printed at the ROP. Figure .AW G282/ is an example of the 1960 page display which shows that a BWM is being made official (name of the BWM is in the upper right-hand corner). In addition to the BWM installation commands, any available paging command may be entered from the 1960 display page. 2 CMD RESULT 9000,Y Starts the updating software session using BWM Y (UPD:UPNAME:BWM=Y) 9010 Verifies the BWM (UPD:VFYBWM) 9560 Stops the execution of the BWM (STP:EXC,UPD) 9565,Z Resets the execution pointer in the message file to command line Z (UPD:RESET:LINE=Z) 9570 Scrolls the message display area forward to the next window (UPD:NXTWNDW) 9575 Scrolls the message display area backward to the previous window (UPD:PRVWNDW) 9110 Displays the APPLY section of the BWM in the message display area (UPD:DISPLYUPD,APPLY) 9120 Displays the SOAK section of the BWM in the message display area (UPD:DISPLYUPD,SOAK) 9130 Displays the OFC section of the BWM in the message display area (UPD:DISPLYUPD,OFC) 9140 Displays the BKOUT section of the BWM in the message display area (UPD:DISPLYUPD,BKOUT) 9150 Displays the FILE section of the BWM in the message display area (UPD:DISPLYUPD,FILE) 9210 Prints the APPLY section of the BWM at the ROP (UPD:PRINT,APPLY) 9220 Prints the SOAK section of the BWM at the ROP (UPD:PRINT,SOAK) 9230 Prints the OFC section of the BWM at the ROP (UPD:PRINT,OFC) 9240 Prints the BKOUT section of the BWM at the ROP (UPD:PRINT,BKOUT) 9250 Prints the whole sections of the BWM at the ROP (UPD:PRINT,FILE) 9260,F Prints the ASCII files that are associated with a particular BWM on the ROP (UPD:PRINT:BWMFILE,FN=F) where F = filename in BWM 9310 Executes all APPLY command lines one by one (UPD:EXALL,APPLY)[,UCL] 9320 Executes all SOAK command lines one by one (UPD:EXALL,SOAK) 9330 Executes all OFC command lines one by one to make a BWM official (UPD:EXALL,OFC)[,UCL] 9340 Executes all BKOUT command lines one by one to back out the BWM (used if the BWM fails) (UPD:EXALL,BKOUT) 9410 Execute current APPLY command line (UPD:EXNXT,APPLY) 9420 Execute current SOAK command line (UPD:EXNXT,SOAK) 9430 Execute current OFC command line (UPD:EXNXT,OFC) 9440 Execute current BKOUT command line (UPD:EXNXT,BKOUT) The 1999 page provides a reference for the use of video attributes for various maintenance states. The 1999 page is for information only. It does not indicate any existing conditions and it does not have any commands. The display is divided into sections for the SUMMARY STATUS AREA STATES, CIRCUIT STATES, and OTHER STATES. The SUMMARY STATUS AREA STATES are only used in the SUMMARY STATUS AREA. The CIRCUIT STATES are used for actual circuit status. These states always have accompanying text describing the condition. The OTHER STATES are used for summary-type indicators and for alarm unit indicators. Although different states are used in different areas, the guidelines listed in the 5ESS Switch States section of the manual are followed in each area. The meanings of the states are as follow: Summary Status Area States o CRITICAL FLASH is used for unacknowledged (not yet retired) severe, service-affecting conditions. These alarms require immediate corrective action. o CRITICAL STEADY is used for acknowledged (retired) CRITICAL ALARMS. o MAJOR FLASH is used for unacknowledged serious disruptions to service or failure of important circuits. These alarms require immediate corrective action but are less urgent than critical alarms. o MAJOR STEADY is used for acknowledged major alarms. o MINOR FLASH is used for unacknowledged troubles that do not have a serious effect on service or for troubles in circuits which are not essential for call processing. o MINOR STEADY is used for acknowledged minor alarms. Note: The indicators CRITICAL, MAJOR, and MINOR do not flash. Only the actual area of the alarm flashes. For example, the SM indicator flashes if the alarm is due to a trouble or an off- normal condition in an SM. o UNALARMED OFF-NORMAL is used for unalarmed troubles. o SYSTEM NORMAL is only used for the SYS NORM indicator and only when there are no off-normal conditions in the system. o NORMAL is used for all the SUMMARY STATUS AREA indicators, except the SYS NORM indicator, when their respective area has no off-normal or trouble conditions. Such as, if the CM hardware has no trouble conditions or off-normal conditions, the CM indicator will be NORMAL. Circuit States o ACT: Active means the circuit is in service, available for normal use by the system. o STBY: Standby means a unit is ready, willing, able, and waiting to perform its intended function. o OOS: Out of service is used for units which have been removed from service and are no longer to be used by the system. o UNV: Unavailable (UNV) is used for units which the system is prevented from using. This condition is initiated by a craft action. o UNEQ: Unequipped is used to show units which are not installed. o IDLE: Idle is used for units that are available for service if needed, but would need to be configured first. o INIT: Initialization is used when a unit is being initialized. o INH: Inhibit means the action which would normally occur is inhibited from doing so. o ACTF: Active forced is used when one side of a duplex unit is forced to active, regardless. The other side of the duplex unit automatically becomes UNV. The ACTF state can only be initiated by a craft action. There may or may not be a fault in the ACTF unit. o DGR: Degraded is used for circuit groupings in which the overall circuitry is functioning normally, although one or more of the noncritical circuits in the grouping is out of service. (For example, this state is used for ONTC X, which includes MI/NC X, TMS X, and all DLIs on side X. If one of the DLIs fails, the ONTC becomes degraded.) o DGRF: Degraded forced is similar to ACTF, but there definitely is a noncritical fault. o LMTD: Limited is used when a circuit is currently active, but a nonservice-affecting request to remove the circuit has been camped on. The circuit will go out of service as soon as it is idle. This would normally appear on line unit and trunk unit circuits. o TEST: This state is used when an operational or functional test other than a diagnostic is being run on a unit. This is a form of testing which can run while a unit is in use (most frequently used for line unit concentrators). o UNVP: Unavailable power is used when a unit is unavailable due to no power to the unit due to a manual action (such as hitting the ``button'' to turn power off to the unit). o UNVT: Unavailable transient is a transient state, shown only to keep the craft informed as to what is happening. No action is required on the part of the craft. o OOSP: Out-of-service power is used when a unit is out of service due to no power to the unit due to faulty hardware (such as a blown fuse or converter failure). o OOST: Out-of-service transient is a transient state, shown only to keep the craft informed as to what is happening. No action is required on the part of the craft. o OOSF: Out-of-service family is used when a circuit goes out of service because its ``parent'' unit has gone out of service. For example, the MMPs in an MSGS would be OOSF if the control unit (MSCU) was out of service. o DEFR: Deferred is used to indicate an out-of-service unit whose return to service has intentionally been deferred. This state can only be entered by a craft action. o GROW: Growth is used while a new unit or capability is being added to the system. o SGRO: Special growth is a semioperational state used when an SM is being added to the system. o CAMP: Camp on is used when a unit is waiting for ownership of some resources. o CDNY: Customer Denied is used for circuit groupings in which the overall circuiting is functioning normally, but some customers are denied service. Other States o SEVERE TROUBLE flashes and is used for fire alarms and isolated SMs. o TROUBLE is used for off-normal alarm unit indicators (except fire) and for off-normal summary indicators. o INHIBITS ON is used for summary-type indicators. o OFF-NORMAL is used for least-significant off-normal conditions on Page 114. o NORMAL is used for normal alarm unit and summary indicators. Figure .AW G283/ shows an example of the 1999 page. Any available paging command can be entered from the 1999 display page. This subsection contains the master control center (MCC) page displays and their descriptions that changed with the 5E7 software release. There are no new page displays for 5E7. Refer to Table .AW TAF/ for a complete listing of MCC page displays. The purpose of the 100 page index is to provide an index of main system pages. This index is a listing of primary maintenance displays and is also an entry point into other subsystem displays, such as trunk and line maintenance, equipment configuration data (ECD), and office dependent data recent change and verify (ODD RC/V). The per-switching module (SM) pages are not shown on this display. The SMs have their own index (1000 - SM PAGE INDEX). There is a direct correlation between the page numbers of Pages 105 through 116 (except 108) and the physical position of the status summary indicators in the SUMMARY STATUS AREA. For example, the fifth status summary indicator in the SUMMARY STATUS AREA (from left to right) is BLDG/PWR. Its associated display is 105 - BLDG/PWR & ALARM CONTROLS. Some of the status summary indicators do not have an associated display page. These are listed on the index as ``NOT ASSIGNED.'' This is a built-in trouble-locating shortcut. The page number for an alarm can be derived from the alarmed indicator's position without going to this display, although this display is always available. Information on ODD can be found in AT&T 235-600-105, Translations Data Manual. Also, all RC/V views are described in AT&T 235-118-2XX (XX = manual number associated to the applicable software release), Recent Change Procedural Manuals. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of RC/V manuals. Information on equipment configuration data/system generation (ECD/SG) RC/V can be found in AT&T 235-600-30X (X = manual number associated to the applicable software release), ECD/SG Data Base Manual. Refer to AT&T 235-000-000, Numerical Index - Division 235 and Associated Documents, for the complete list of ECD/SG manuals. Pages 196, 198, and 199 (RC/V pages) do not appear when the 100 Page Index page is displayed at the switching control center (SCC) because the RC/V pages cannot be displayed at that location. Page 118 (CNI STATUS) is shown depending on switch configuration. Figure .AW G284/ shows an example of the 100 page index. The commands on this page can be entered from any display page, under normal operation. Also, any available per-SM display can be accessed. See 1000 - SM PAGE INDEX (Figure .AW G299/) for details. 2 CMD RESULT 100 PAGE INDEX is displayed 105/106 BUILDING/POWER AND ALARM CONTROLS page is displayed 107 CIRCUIT LIMIT page is displayed 109 OVERLOAD page is displayed 110 SYSTEM INHIBITS page is displayed 111/112 AM, AM PERIPHERALS page is displayed 113 OPERATIONS SYSTEMS LINKS page is displayed 114 EQUIPPED SM STATUS SUMMARY page is displayed 115 COMMUNICATION MODULE SUMMARY page is displayed 116 MISCELLANEOUS page is displayed 117 IOP APPLICATION PROCESSOR DATA LINKS page is displayed 118 COMMON NETWORK INTERFACE FRAME AND COMMON CHANNEL SIGNALING LINK STATUS page is displayed 119 MISCELLANEOUS ALARMS page is displayed 120 MESSAGES page is displayed 121 IOP 0 & 1 page is displayed 122 IOP 2 & 3 page is displayed 123 DISK FILE SYSTEM ACCESS DFC 0-1 page is displayed 124 SOFTWARE RELEASE RETROFIT page is displayed 125 DISK FILE SYSTEM ACCESS DFC 2-3 page is displayed 126 DFSA PERFORMANCE DFC 0-1 page is displayed 127 MTIB page is displayed 128 DFSA PERFORMANCE DFC 2-3 page is displayed 129 DEFENSE SERVICES NETWORK NM EXCEPTION page is displayed 130 NM EXCEPTION page is displayed 131 CALL TRACE MENU page is displayed 160 TRUNK AND LINE MAINTENANCE INDEX is displayed 178 AUTO SPARE DISK page is displayed 179 DISK CONFIGURATION page is displayed 180 DISK CONFIGURATION page is displayed 181 OFFLINE SM 1-48 STATUS SUMMARY page is displayed 182 OFFLINE SM 49-96 STATUS SUMMARY page is displayed 183 OFFLINE SM 97-144 STATUS SUMMARY page is displayed 184 OFFLINE SM 145-192 STATUS SUMMARY page is displayed 190 C/D UPDATE page is displayed 191 OS STATUS page is displayed 193 VERIFY TEXT page is displayed 194 SCREEN page is displayed 195 GENBACKUP page is displayed 196 ODD RC/V is started. NOT FOR USE FROM SCC 197 CUTOVER page is displayed 198 SG RC/V is started. NOT FOR USE FROM SCC 199 ECD RC/V is started. NOT FOR USE FROM SCC 1000 SM PAGE INDEX page is displayed 1209 ONTC 0 & 1 page is displayed 1210 MI/NC 0 & 1 page is displayed 1220 TMS 0 & 1 SUMMARY page is displayed 1240 MSGS 0 SUMMARY page is displayed 1250 MSGS 1 SUMMARY page is displayed 1260 CLNK SUMMARY page is displayed 1271 REX STATUS page is displayed 1850 CMP INHIBIT AND RECOVERY CONTROL page is displayed 1940 EASY BWM INSTALLATION page is displayed 1950 PROGRAM UPDATE MAINTENANCE MENU page is displayed 1960 BWM INSTALLATION page is displayed 1999 STATE DEFINITIONS page is displayed The 109 display page provides an indication of resource or real-time overloads in the administrative module (AM), communication module processor (CMP), and SM(s) and commands to inhibit or allow essential service protection (ESP).